subtle issue with systemd, dnf 'greedy' obsoletes behaviour, and multiple repos

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

A key factor here is that, for any given Fedora release, the packages
that made up that release at the time it was initially released will
always be available to DNF, in the repository called 'fedora'. This
repository maps to the "frozen" release tree; for Fedora 32, for
instance, it maps to
https://dl.fedoraproject.org/pub/fedora/linux/releases/32/Everything/ .
If we release with foo-1.0-1, then send out foo-1.0-2 and then foo-1.0-
3 as updates, then when 1.0-3 goes stable, 1.0-2 is no longer visible
to DNF, because 1.0-3 replaced it in the 'updates' repository...but
1.0-1 is *always* visible to DNF, because it is in the 'fedora'
repository, and that repository never changes.

So the bug openQA caught is that, with the systemd update available,
upgrading from Fedora 31 to Fedora 32 no longer works if the package
u2f-hidraw-policy is installed. You can see the failure here:
https://openqa.fedoraproject.org/tests/608480#step/upgrade_run/54

On further investigation, I found the "culprit" is ultimately this
commit:
https://src.fedoraproject.org/rpms/systemd/c/80532792aa6f988d34f18ce1ffdfa992be9cb402?branch=master
which happened between 245.4-1.fc32. and 245.6-1.fc32. Before
that commit, the subpackage 'systemd' Obsoletes: u2f-hidraw-policy .
After that commit, the obsolete is moved to the 'systemd-udev'
subpackage. So systemd-245.4-1.fc32 Obsoletes: u2f-hidraw-policy ,
and so does systemd-udev-245.6-1.fc32 .

Now, as I noted above, 245.4-1.fc32 is in the frozen 'fedora' repo for
F32, so systemd-245.4-1.fc32 is always available to DNF. With this
update in play, systemd-udev-245.6-1.fc32 is also available to DNF.

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

So what DNF does when we try to upgrade is try to include *both*
systemd-245.4-1.fc32 and systemd-udev-245.6-1.fc32 in the operation,
because it sees both as available, F32 packages that obsolete an
installed package. And that blows up because of obvious dependency
problems (systemd-udev-245.6-1.fc32 requires systemd-245.6-1.fc32, but
we can't install both systemd-245.4-1.fc32 and systemd-245.6-1.fc32 at
the same time).

It was actually a bit tricky to come up with a solution for this. I
hacked up a minimal reproducer with empty packages, and experimented a
bit, and 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.

I was worried that if you had u2f-hidraw-policy and systemd installed,
but not systemd-udev, this Obsoletes: might lead to systemd-udev
getting installed on upgrade. However, it does not seem to: DNF is
happy just updating systemd to 245-6.1.fc32, which is not obsoleted by
the same-versioned systemd-udev, correctly realizing that this
satisfies all constraints and it doesn't need to pull in systemd-udev.

Another possible solution that would I guess work but be kinda finicky
would be to update u2f-hidraw-policy in F31 to 1.0.2-40.fc31, and then
bump the Obsoletes: in systemd-udev to < 1.0.2-50. That would
effectively "disarm" the `Obsoletes: u2f-hidraw-policy < 1.0.2-40` in
systemd-245.4-1.fc32. This fix would rely on people updating their F31
install before upgrading to F32, though (which we always say you're
supposed to do, but of course some people don't).

As a P.S., I've actually seen a variant of this problem before, where a
packager tried to "remove" an Obsoletes: with an update - that didn't
really work, because the Obsoletes: was still present in the version of
the package in the frozen 'fedora' repo, so removing the Obsoletes:
from a later build of the package in the 'updates' repo didn't actually
stop the other package being removed on upgrade to the release in
question. It still got removed, and replaced with the *older* version
of the 'replacement' package from the 'fedora' repo. Then on the next
`dnf update` the old version of the 'replacement' package would be
updated to the newer version from the 'updates' repo, from which the
Obsoletes: had been removed...

So, that's the story so far :) If anyone has thoughts, questions,
suggestions or concerns about my proposed fixes, please chip in! And
keep this kind of wrinkle in mind for the future :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux