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 _______________________________________________ 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
