On Tue, 2020-06-02 at 06:37 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jun 01, 2020 at 02:10:12PM -0700, Adam Williamson wrote:
> Hi folks! openQA caught a subtle issue in a systemd update over the
> weekend, and I thought it would be worth flagging up here both to let
> people know about it and also to see if anyone has a better solution
> than the one I came up with.
>
> The issue affects this systemd update for F32:
>
https://bodhi.fedoraproject.org/updates/FEDORA-2020-dd43dd05b1
> that update provides systemd-245.6-1.fc32 . The stable release of
> Fedora 32 contains systemd-245.4-1.fc32.
Hi Adam,
thanks for the deep investigation (and also for setting up onenqa in the
first place, I don't think we'd have caught the issue otherwise.)
> Another factor here is that DNF's behaviour when multiple different
> available packages obsolete an installed package on update is 'greedy'.
> If 'bar', 'moo' and 'meep' all obsolete 'foo' and
are available on
> update, DNF will try to install *all three*. This is intentional and
> necessary when e.g. a package is split in two and we want both the new
> packages to be installed in place of the old one. (If it's just
> multiple available versions of the *same* package that all obsolete an
> installed package, DNF will simply try to select the newest one as part
> of the update, which is fine).
I think this "greedy" behaviour is correct: we rely on this to allow
package splits. There was some discussion whether dnf is in the wrong here,
but it seems to be doing everything correctly.
I can think of potential refinements to dnf's behaviour here, though I
imagine the internal ordering of this whole dependency resolution
process is a bunch of fun already. As a dumb simplification you could
float: "only consider the *highest available version* of any given
package as a candidate for obsoleting other packages", though I think
it is too simple: what if we're in a case where the newer build of
package Z in updates-testing has problems, so outside of Obsoletes:
questions dnf would choose to update to the older build of package Z in
updates? Still, it feels like an area where it *should* be possible to
improve dnf's behaviour somehow. (though I guess this may well be in
libsolv anyway).
> the solution I was able to find that works is to have systemd-
> udev Obsoletes: systemd < 245.6-1. This seems to correctly clue DNF in
> to the situation and cause it to leave out anything from 245.4-1.fc32
> in the upgrade.
Yep, this sounds like the correct solution. systemd-udev Requires systemd,
and systemd is only provided by systemd, so there doesn't seem to be any
chance of systemd getting uninstalled.
Great. I see you went ahead and did that, so it looks like we're good
now. Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net