MSYS2-packages: Updating MSYS2 unattended is broken (MSYS2 locks up on full system upgrade)

The idea was that nobody added --ask to start with (I’m almost sorry now that I mentioned the option before) or if they did they were aware it was a temporary workaround.

If it really causes issues for people (although - how many might it affect but the few who read this issue?) then we might consider reverting. However I still feel deeply that down the road requiring every potential CI / script user to a) find and b) understand the --ask option and to apply it properly to their scripts is an unnecessary burden.

For me personally removing the flag as soon as the pacman update has landed seems more acceptable than to require everybody else to use the arcane flag down the road. Basically the sheer fact that this flag makes it possible to cause troubles like this should be a large indication for everybody that it’s usage is to be avoided at all cost.

Also consider that the same would happen if upstream decided to apply this change (and they’d be well within their rights to do so as nobody could blame them for changing the meaning of an internal option that was not supposed to be used in production to start with).

FWIW, while pacman itself is not really targeted at fully noninteractive scripting use, the pacutils collection of libalpm frontends (created by one of the lead pacman developers) has a pacinstall/pacremove/pactrans program which contains a series of options under the heading Prompt Disposition Options.

There is a catchall option too:

--yolo
    Set all prompt disposition options to their all or yes value and set --no-confirm.

So for completely unattended use, pacsync && pacinstall --sysupgrade --yolo will automatically install all upgrades without user interaction, while automatically answering yes to all questions or otherwise optimistically attempting to resolve any prompt option.

Maybe you’d be interested in packaging pacutils?

In KDE Craft we have a blueprint that installs msys, its not perfect but works so far. Today I added the --ask flag to make the blueprint work for now. But as far as I understand this change, --ask will make it work for the first few pacman updates but as soon as pacman is updated to the version containing this patch it will break? I think the fastest approach here is to not patch pacman but to provide a new base package which has no initial conflict. I agree with @jtanx that the usecase here are CI and onetime scripted installs.

https://github.com/KDE/craft-blueprints-kde/blob/master/dev-util/msys/msys.py

Even found a workaround for it that does not require a code change:
Pacman has an undocumented option --ask that takes a number, which is then converted into a bitmask and is used to override the default answer to questions (so we can use --noconfirm again).

The bit mask can be derived from the question type as defined in the enum _alpm_question_type_t, the default answer is overridden here.

It’s certainly ugly and the option was even removed at one point for being “non-user friendly” but added back later (mainly for internal usage, though) but it allows CI to work again!

Maybe removing the blocking behavior is still the easiest solution (probably better than using an undocumented option?). Otherwise we could still attempt to change the defaults, but there does not seem to be a straightforward way to do it (at least I did not find the defaults collected in a central place, it seems they’re defined at multiple locations in the code…)

We could ask pacman upstream to add a “–yes” option which is equal to “–ask 20” now.

Or make the “warning: terminate MSYS2 without returning” warning non-blocking (does it really have to be?) so one can pipe yes.

I agree that --ask 20 is not ideal, but given that the use case is CI, you would only have to set it once and forget about it, making it more or less a non-issue.

I also agree that having some way to confirm with yes (and without using an undocumented flag) is a needed feature - but I disagree with changing the default behaviour of the flag (and which I infer now also breaks the --ask flag). I disagree because it’s a breaking change in the subtlest of ways - sure, it may not be what you would want the flag to do as it stands, but there may already be things depending on this behaviour of not overwriting/upgrading what exists. It’s also another behavioural difference to vanilla pacman, which may surprise anyone used to that instead of this msys2 flavour.

As mentioned before, given that there is a workaround in vanilla pacman (--ask 20), this should have just been proposed upstream, or if you really must, patched as a separate flag (like --noconfirm-yes).

I too think the better option is to somehow “document” undocumented --ask and return to the original behavior. I doubt that people expect such change in the pacman habits and will be really surprised. Not everyone follows msys2 commits. it’s up to you of course.

Yeah, to be honest, diverging behaviour on the same flag as arch pacman sounds bad. The patch would be better if the new behaviour was another option, or better yet, get this change (in some form) upstreamed. Or just stick with --ask 20…

Since i can never be sure what version of pacman i have on remote host your change will actually complicate things for me 😕 . It means i can’t write a script to unattendedly update from unknown version to the last one.

@Ede123 nice find! As far as I can see it just reverses the default answer, and only two commands are defaulting to NO using noyes(), ALPM_QUESTION_CONFLICT_PKG and ALPM_QUESTION_REMOVE_PKGS, so “–ask 20” should make it default to yes for everything.

@Alexpux I found the issue:

• if pacman is run with --noconfirm it does not wait but return immediately after full system upgrade, see here
• however if pacman is run with --noconfirm it assumes “no” for the question $1 and $2 are in conflict. Remove $2? [y/N]
• in my last change I removed to --noconfirm to account for #1139 which in turn caused the blocking behavior

I think we simply need to either a) change the default answer to the “remove?” question b) make pacman return in this case