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.
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.
Zbyszek