Date: Mon, 3 Jun 2019 09:45:33 +0300
From: Timo Teras <timo.teras@iki.fi>
To: "A. Wilcox" <AWilcox@Wilcox-Tech.com>
Cc: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] [PATCH 0/1] apk upgrade has issues when old deps
 still available
Message-ID: <20190603094533.782ca468@vostro>
In-Reply-To: <20190601042516.56133-1-AWilcox@Wilcox-Tech.com>
References: <20190601042516.56133-1-AWilcox@Wilcox-Tech.com>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.
>=20
> This causes considerable breakage for at least Ad=C3=A9lie 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].
>=20
> 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].
>=20
> [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
---