When running `apk upgrade -al` only packages listed in the world file are
forced to upgrade. If a package in world has a dependency that is eligible
for upgrade, but the currently installed version is also still available in
the repository, it will not be considered for upgrade.
This causes considerable breakage for at least Adélie Linux; we keep built
packages around on the mirrors indefinitely. This breakage was noticed
during upgrades of 1.0-BETA2 to 1.0-BETA3, and the solver log (using
DEBUG_PRINT) can be seen at [1].
The patch I am sending fixes this issue for us by adding an option to the
upgrade applet, '-d' or '--deep', which causes the solver to prefer newer
versions of all selected packages when available. The difference in the
solver log can be seen at [2].
[1]: https://www.adelielinux.org/storage/apk-error.log
[2]: https://www.adelielinux.org/storage/deep.diff
A. Wilcox (1):
upgrade: add --deep option to upgrade everything
src/apk_solver.h | 1 +
src/solver.c | 10 ++++++++++
src/upgrade.c | 5 +++++
3 files changed, 16 insertions(+)
--
2.21.0
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
[alpine-devel] [PATCH 1/1] upgrade: add --deep option to upgrade everything
On 06/03/19 01:45, Timo Teras wrote:
> Hi,> > On Fri, 31 May 2019 23:25:15 -0500> "A. Wilcox" <AWilcox@Wilcox-Tech.com> wrote:> >> When running `apk upgrade -al` only packages listed in the world file>> are forced to upgrade. If a package in world has a dependency that>> is eligible for upgrade, but the currently installed version is also>> still available in the repository, it will not be considered for>> upgrade.>>>> This causes considerable breakage for at least Adélie Linux; we keep>> built packages around on the mirrors indefinitely. This breakage was>> noticed during upgrades of 1.0-BETA2 to 1.0-BETA3, and the solver log>> (using DEBUG_PRINT) can be seen at [1].>>>> The patch I am sending fixes this issue for us by adding an option to>> the upgrade applet, '-d' or '--deep', which causes the solver to>> prefer newer versions of all selected packages when available. The>> difference in the solver log can be seen at [2].>>>> [1]: https://www.adelielinux.org/storage/apk-error.log>> [2]: https://www.adelielinux.org/storage/deep.diff> > Thanks for the debug logs, and analysis so far. I have seen this also> once or twice and been wondering what is causing it.> > However, instead of adding yet another switch. I'd like to fix the root> cause and make this default behaviour. Furthermore, I think the patch> suggested breaks at least package pinning.> > Was any package pinning used?> > Is there any cycles, or errors in the repository? E.g. does "apk dot> --errors --installed" see anything problematic?> > Do you have an easy way for me to duplicate this setup, to further> analyze the issue?> > It is likely related to the solver doing things in wrong order which> causes some of the dependency inherited flags to not be available at> the time when the dependency gets processed.> > Thanks,> Timo
We rarely use package pinning over here, so it wasn't in use on any of
the computers that hit this bug.
The easiest way that I can think of for you to duplicate it would be to
install Adélie beta2 with qt5-qtbase-dev in a chroot, then attempt to
upgrade it to beta3:
# mkdir /test
# apk --root /test -X
https://distfiles.adelielinux.org/adelie/1.0-beta2/system -X
https://distfiles.adelielinux.org/adelie/1.0-beta2/user
--allow-untrusted --initdb add adelie-base qt5-qtbase-dev
# apk --root /test -X
https://distfiles.adelielinux.org/adelie/1.0-beta3/system -X
https://distfiles.adelielinux.org/adelie/1.0-beta3/user upgrade -al
On the x86_64 machine I tested this on, there was a slightly different
error, but the same cause/effect:
Upgrading critical system libraries and apk-tools:
(1/1) Upgrading apk-tools (2.10.3-r0 -> 2.10.3-r1)
Continuing the upgrade transaction with new apk-tools:
ERROR: unsatisfiable constraints:
libpcrecpp-8.42-r1:
breaks: pcre-dev-8.43-r0[libpcrecpp=8.43-r0]
(If you don't want to use --allow-untrusted for the initial install, you
can manually extract our adelie-keys apk.)
It looks like there are two cycles shown in dot, one that we should
probably fix (util-linux deps on libfdisk which deps on util-linux) and
one that isn't really fixable (bash deps on /bin/sh because it has an
install script, and /bin/sh is provided by bash-binsh which is part of
bash). Neither of these seem to be related to the issue, but I may be
wrong.
I would really like to have this be the default behaviour but was unsure
if it would be desired; I'm glad to hear that it is. Thank you for
looking in to this. If you need more information, let me know.
Best to you and yours,
--arw
--
A. Wilcox (awilfox)
Open-source programmer (C, C++, Python)
https://code.foxkit.us/u/awilfox/
Hi,
On Fri, 31 May 2019 23:25:15 -0500
"A. Wilcox" <AWilcox@Wilcox-Tech.com> wrote:
> When running `apk upgrade -al` only packages listed in the world file> are forced to upgrade. If a package in world has a dependency that> is eligible for upgrade, but the currently installed version is also> still available in the repository, it will not be considered for> upgrade.> > This causes considerable breakage for at least Adélie Linux; we keep> built packages around on the mirrors indefinitely. This breakage was> noticed during upgrades of 1.0-BETA2 to 1.0-BETA3, and the solver log> (using DEBUG_PRINT) can be seen at [1].> > The patch I am sending fixes this issue for us by adding an option to> the upgrade applet, '-d' or '--deep', which causes the solver to> prefer newer versions of all selected packages when available. The> difference in the solver log can be seen at [2].> > [1]: https://www.adelielinux.org/storage/apk-error.log> [2]: https://www.adelielinux.org/storage/deep.diff
Thanks for the debug logs, and analysis so far. I have seen this also
once or twice and been wondering what is causing it.
However, instead of adding yet another switch. I'd like to fix the root
cause and make this default behaviour. Furthermore, I think the patch
suggested breaks at least package pinning.
Was any package pinning used?
Is there any cycles, or errors in the repository? E.g. does "apk dot
--errors --installed" see anything problematic?
Do you have an easy way for me to duplicate this setup, to further
analyze the issue?
It is likely related to the solver doing things in wrong order which
causes some of the dependency inherited flags to not be available at
the time when the dependency gets processed.
Thanks,
Timo
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---