Update to Cygwin 3.5 - The end for Windows 7/8

[lazka]

Once we update to cygwin 3.5, users still on Windows 7/8 who upgrade will break their installation.

The PR for this would be #4422

Currently ~0.5% of users are affected, but it's not clear how many of them update things. #2832 (comment)

I guess the next thing is to write a NEWS entry for them, tell them how to fix their install if it's broken, and that they can't update anymore.

[lazka]

Someone suggested to use the pre_install/upgrade script to abort things.

[lazka]

IgnorePkg = msys2-runtime in /etc/pacman.conf also works.

And as noted, having a 3.4 package should be viable: #4422 (comment)

[lazka]

[jeremyd2019]

When installing msys2-runtime-3.3, I tend to use exec pacman ... to try to reduce the issues with the fact that those are not "core" packages so anything running after they're installed is likely to be broken. I use Windows Terminal, and root my terminal processes with env (to set MSYSTEM) so I don't know if that will work out as well for people who use mintty/launcher exe/msys2_shell.cmd

[lazka]

Yeah, it wont be as smooth as a normal update. We could do a "startswith msys2-runtime" or check its provides to treat it as a core update.

edit: I've filed msys2/msys2-pacman#39

[angelog0]

I see that 3.5 is in MSYS2

$ pacman -Ss msys2-runtime | grep msys2
msys/msys2-runtime 3.4.10-8 [installato]
msys/msys2-runtime-3.3 3.3.6-9
msys/msys2-runtime-3.3-devel 3.3.6-9
msys/msys2-runtime-3.4 3.4.10-1
msys/msys2-runtime-3.4-devel 3.4.10-1
msys/msys2-runtime-3.5 3.5.3-1
msys/msys2-runtime-3.5-devel 3.5.3-1
msys/msys2-runtime-devel 3.4.10-8 [installato]

but on

$ uname
MSYS_NT-10.0-19045

still 3.4 is installed. Why?

[lazka]

I see that 3.5 is in MSYS2

So we can test it. I've been using it locally for the last few weeks. This will change with #4580

[lazka]

With #4576 in the repo now Windows 7 users will see pacman abort and the message suggesting the move to msys2-runtime-3.4 (see screenshot above)

Next steps:

• Announce in the NEWS section -> msys2/msys2.github.io@84d8d03
• Update to 3.5: msys2-runtime: Update to 3.5.3 #4580

[lazka]

All done now.

[cbrt64]

@lazka When I updated today on Windows 10, the pre_upgrade appears to have been attempted (and failed) after the runtime was installed.

As you've already noticed, it works fine with pacman -U. I suspect there may be something wrong in pacman's special-case code for the core system upgrade, but haven't looked yet; I thought it best to give you a heads up before any Windows 7 people get caught out by this.

pacman -Su

$ pacman -Su
:: Starting core system upgrade...
warning: terminate other MSYS2 programs before proceeding
resolving dependencies...
looking for conflicting packages...

Package (3)               Old Version  New Version  Net Change

msys/msys2-runtime        3.4.10-8     3.5.3-1        0.19 MiB
msys/msys2-runtime-devel  3.4.10-8     3.5.3-1        0.03 MiB
msys/pacman               6.0.2-14     6.0.2-15       0.13 MiB

Total Installed Size:  50.40 MiB
Net Upgrade Size:       0.35 MiB

:: Proceed with installation? [Y/n]
(3/3) checking keys in keyring                                           [#######################################] 100%
(3/3) checking package integrity                                         [#######################################] 100%
(3/3) loading package files                                              [#######################################] 100%
(3/3) checking for file conflicts                                        [#######################################] 100%
:: Processing package changes...
(1/3) upgrading msys2-runtime                                            [#######################################] 100%
      1 [main] pacman (12684) shared_info::initialize: size of shared memory region changed from 58296 to 57272
                                                                                                                     0 [main] bash (5552) shared_info::initialize: size of shared memory region changed from 58296 to 57272
error: command (/usr/bin/bash /usr/bin/bash -c . /tmp/alpm_VNTyuw/.INSTALL; pre_upgrade 3.5.3-1 3.4.10-8 ) failed to execute correctly
(2/3) upgrading msys2-runtime-devel                                      [#######################################] 100%
(3/3) upgrading pacman                                                   [#######################################] 100%
:: To complete this update all MSYS2 processes including this terminal will be closed. Confirm to proceed [Y/n]

[cbrt64]

I had a PreTransaction Install/Upgrade hook (tested with pacman -U) in place as well, that was completely ignored.

[lazka]

I've reverted the update script change today to rule out any problems re #4585 (and adjusted the NEWS entry on the website accordingly).

The "failed" thing you saw is I think just because the script is also called after the update, so in theory it failing there shouldn't matter. But I reverted it to be save. I'd rather have working upgrades then make things easier for win 7 users.

Hooks are ignored for core upgrades: msys2/msys2-pacman@9d91ab9#diff-5add07940112341f59fe3817d1d534ef87c348c83ea1109660789d444e93da5aR810

[cbrt64]

Thanks for the info! I maybe found an easy way to fix the annoying errors.

The "failed" thing you saw is I think just because the script is also called after the update, so in theory it failing there shouldn't matter.

The thing that puzzled me was, why is pre_upgrade() running after the runtime package is installed, instead of before? After a bit of looking, the answer is too simple: it's running twice, each time as expected before a package is installed, once each for msys2-runtime and msys2-runtime-devel.

So I rolled my installation back and re-updated with a locally built 3.5.3-1, adding a printf to check the install script and moving install= to package_msys2-runtime(), and got acceptable and repeatable results.

pacman -Su # (Windows 10)

$ pacman -Su
:: Starting core system upgrade...
warning: terminate other MSYS2 programs before proceeding
resolving dependencies...
looking for conflicting packages...

Package (3)               Old Version  New Version  Net Change

msys/msys2-runtime        3.4.10-8     3.5.3-1        0.19 MiB
msys/msys2-runtime-devel  3.4.10-8     3.5.3-1        0.03 MiB
msys/pacman               6.0.2-14     6.0.2-15       0.13 MiB

Total Installed Size:  50.40 MiB
Net Upgrade Size:       0.35 MiB

:: Proceed with installation? [Y/n]
(3/3) checking keys in keyring                                           [#######################################] 100%
(3/3) checking package integrity                                         [#######################################] 100%
(3/3) loading package files                                              [#######################################] 100%
(3/3) checking for file conflicts                                        [#######################################] 100%
:: Processing package changes...
      Checking Windows version...
(1/3) upgrading msys2-runtime                                            [#######################################] 100%
(2/3) upgrading msys2-runtime-devel                                      [#######################################] 100%
(3/3) upgrading pacman                                                   [#######################################] 100%
:: To complete this update all MSYS2 processes including this terminal will be closed. Confirm to proceed [Y/n]

Maybe I'm missing something and this is all wrong, so I'll let you decide if you want to implement it.

[cbrt64]

Hooks are ignored for core upgrades

After looking at the code base I can see it would be challenging to selectively disable post- hooks for core.

But a pre- hook with [Action] AbortOnFail is arguably the "right" solution for the use case of canceling a pacman transaction, since install scripts run adjacent to their respective packages, introducing the possibility of killing a partially completed transaction.

This may not be as bad as I'm thinking; what I don't know is:

1. Is it safe to assume that msys2-runtime is always first in a core update?
2. Can a partially completed upgrade be harmful anyway?

Just thinking out loud.