No way to download packages only in case of a conflict

[przemoc]

Description / Steps to reproduce the issue

pacman -Suw fails, but I think it should ask series of questions similarly like pacman -Su does.

Expected behavior

Successful download of upgraded packages.

Actual behavior

przemoc@NUC11PHKi7C002 MSYS ~
$ pacman -Suw
:: Starting core system upgrade...
 there is nothing to do
:: Starting full system upgrade...
resolving dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: installing mingw-w64-i686-gcc (14.1.0-2) breaks dependency 'mingw-w64-i686-gcc=13.2.0-6' required by mingw-w64-i686-gcc-ada
:: installing mingw-w64-i686-gcc-libs (14.1.0-2) breaks dependency 'mingw-w64-i686-gcc-libs=13.2.0-6' required by mingw-w64-i686-gcc-ada
:: installing mingw-w64-i686-gcc (14.1.0-2) breaks dependency 'mingw-w64-i686-gcc=13.2.0-6' required by mingw-w64-i686-gcc-objc
:: installing mingw-w64-i686-gcc-libs (14.1.0-2) breaks dependency 'mingw-w64-i686-gcc-libs=13.2.0-6' required by mingw-w64-i686-gcc-objc
:: installing mingw-w64-i686-gcc (14.1.0-2) breaks dependency 'mingw-w64-i686-gcc=13.2.0-6' required by mingw-w64-i686-libgccjit
:: installing mingw-w64-i686-gcc-libs (14.1.0-2) breaks dependency 'mingw-w64-i686-gcc-libs=13.2.0-6' required by mingw-w64-i686-libgccjit

Verification

• [X] I have verified that my MSYS2 is up-to-date before submitting the report (see https://www.msys2.org/docs/updating/)

Windows Version

MSYS_NT-10.0-22631

MINGW environments affected

• [ ] MINGW64
• [X] MINGW32
• [ ] UCRT64
• [ ] CLANG64
• [ ] CLANG32
• [ ] CLANGARM64

Are you willing to submit a PR?

No

[lazka]

It looks like it is that way on purpose: https://gitlab.archlinux.org/pacman/pacman/-/blob/master/src/pacman/pacman.c#L772 since https://gitlab.archlinux.org/pacman/pacman/-/commit/1bd8f57a183db0b9be503eeff3027c4b8d65627d

We could ask upstream about it, if there is a good usecase/reason.

[przemoc]

Thank you for providing origin of this behavior. I suspect it's to ensure non-interactiveness of --downloadonly, but it feels like such feature should be configured separately and not enforced.

My usecase, not sure whether it's a good one, is that I always download first (one pacman invocation) before installing (another pacman invocation). And this behavior makes it impossible to do, unless I'm missing something.

[lazka]

Thank you for providing origin of this behavior. I suspect it's to ensure non-interactiveness of --downloadonly, but it feels like such feature should be configured separately and not enforced.

Good point. We patch pacman to make "--noconfirm" default to resolving the conflict https://github.com/msys2/msys2-pacman/commit/bb871d9ce93da8eda3775432f597061dfcc1e99e With upstream pacman there is no good way to have it non-interactive with conflicts.

[lazka]

I've moved this issue to our pacman fork, but I'm currently unsure on how to proceed.

[przemoc]

Just a follow up to my own comment:

I suspect it's to ensure non-interactiveness of --downloadonly

Isn't pacman -Suw interactive anyway, as you have to confirm that you want to proceed with download? (That is unless someone uses --noconfirm if I'm not mistaken.)

So I'm thinking if it wouldn't be better to add ALPM_TRANS_FLAG_NOCONFLICTS flag only when noconfirm is set, or something like that.

[przemoc]

I've moved this issue to our pacman fork,

Thanks. I should have created it here from the get go.

but I'm currently unsure on how to proceed.

My idea expressed in previous comment may be sufficient way to deal with it, or so I hope, but I am not familiar with pacman source code, so there may be some corner cases which make it harder than it seems on the surface.

I will try to report the issue upstream. I don't have Arch Linux account yet, but requested one. I'll link here upstream ticket after creating it.

[przemoc]

I just created upstream issue: https://gitlab.archlinux.org/pacman/pacman/-/issues/138

[allanmcrae]

This error has nothing to do with conflicts. Hence you are not being asked any questions.

It is due to a failure in dependency resolution (gcc is updated but gcc-{ada,objc,libgccjit} are not?). Using -d would work around this issue. Using -y would probably fix it!

[allanmcrae]

In fact... with conflicts, the ALPM_TRANS_FLAG_NOCONFLICTS flag means this would just plow on through and download the packages.

[przemoc]

This error has nothing to do with conflicts. Hence you are not being asked any questions.

When pacman -Su (i.e. without --downloadonly) is run it looks like this:

$ pacman -Su
:: Starting core system upgrade...
 there is nothing to do
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
:: mingw-w64-i686-gcc and mingw-w64-i686-gcc-objc are in conflict. Remove mingw-w64-i686-gcc-objc? [Y/n] y
:: mingw-w64-i686-gcc and mingw-w64-i686-gcc-ada are in conflict. Remove mingw-w64-i686-gcc-ada? [Y/n] y
:: mingw-w64-i686-gcc and mingw-w64-i686-libgccjit are in conflict. Remove mingw-w64-i686-libgccjit? [Y/n] y

Packages (21) mingw-w64-clang-x86_64-cmake-3.29.3-2
              mingw-w64-clang-x86_64-ninja-1.12.1-1
              mingw-w64-i686-gcc-14.1.0-2
              mingw-w64-i686-gcc-ada-13.2.0-6 [removal]
              mingw-w64-i686-gcc-fortran-14.1.0-2
              mingw-w64-i686-gcc-libgfortran-14.1.0-2
              mingw-w64-i686-gcc-libs-14.1.0-2
              mingw-w64-i686-gcc-objc-13.2.0-6 [removal]
              mingw-w64-i686-libgccjit-13.2.0-6 [removal]
              mingw-w64-ucrt-x86_64-cmake-3.29.3-2
              mingw-w64-ucrt-x86_64-cmake-docs-3.29.3-2
              mingw-w64-ucrt-x86_64-gcc-14.1.0-2
              mingw-w64-ucrt-x86_64-gcc-ada-14.1.0-2
              mingw-w64-ucrt-x86_64-gcc-fortran-14.1.0-2
              mingw-w64-ucrt-x86_64-gcc-libgfortran-14.1.0-2
              mingw-w64-ucrt-x86_64-gcc-libs-14.1.0-2
              mingw-w64-ucrt-x86_64-gcc-objc-14.1.0-2
              mingw-w64-ucrt-x86_64-github-cli-2.49.1-1
              mingw-w64-ucrt-x86_64-libgccjit-14.1.0-2
              mingw-w64-ucrt-x86_64-ninja-1.12.1-1
              mingw-w64-ucrt-x86_64-nss-3.100-1

Total Download Size:    206.80 MiB
Total Installed Size:   949.50 MiB
Net Upgrade Size:      -166.88 MiB

:: Proceed with installation? [Y/n]

So it has been linked to conflicts due to messages like mingw-w64-i686-gcc and mingw-w64-i686-gcc-objc are in conflict. Are those messages incorrect?

It is due to a failure in dependency resolution (gcc is updated but gcc-{ada,objc,libgccjit} are not?). Using -d would work around this issue.

Using pacman -Suwd does seem to work. There are no errors now. Thank you. You call it workaround, so is there a better/proper solution to this situation?

Using -y would probably fix it!

Initially I did -Syuw, but using -y aka --refresh doesn't change anything in this situation, therefore I didn't mention -y in the command when creating ticket.

[lazka]

gcc is updated but gcc-{ada,objc,libgccjit} are not?)

gcc-ada had a versioned dependency on gcc previously. In the new update gcc-ada was completely dropped from the repo. To allow users that had gcc-ada installed to upgrade smoothly we added a conflict to the main gcc package on gcc-ada, so that if gcc is upgraded gcc-ada is removed first. (using ada as an example, the same is true for objc,libgccjit)

[allanmcrae]

Ah - a complicated update... -Suw ignored the conflicts and tried to progress but hit dependency version errors.

Interesting question whether we should ignore dependency errors on -Suw. We still want dependency resolving to happen, so at most I would consider ignoring version only dependency issues. But I am not at all convinced that is a good idea!