On Sat, Oct 5, 2019 at 7:37 AM Rodger Etz <reb(a)brownsen.net> wrote:
Thanks, Chris! I did so, but reboot did not create a debugdata dir. Therefore I have
uploaded the dnf logs.
From what I have seen so far, it still seems the best option to modify system-upgrade so
it safes the transaction before reboot and reboot reruns it ... or something similar.
Trying to figure out what obscure dependency constellation this is causing, will be
painful and most likely fail, because we do not have enough information and the state of
dependencies changes so quickly, the issue might not occur after the next update of those
packages. And even if we find this particular one, it might be there are others as well.
Is it worth it to start a discussion on devel@ ?
Yes. The questions are, is it working as intended and is there a way
to make it work better?
Also I'm curious if the behavior of 'dnf system-upgrade' differs from
gnome-software/PackageKit method. I don't think this problem can be
release blocking for two reasons: the Beta criterion for upgrades is
narrowly written to exclude anything that makes it "not clean" and 3rd
party stuff definitely isn't covered.
"For each one of the release-blocking package sets, it must be
possible to successfully complete a direct upgrade from a fully
updated, clean default installation of each of the last two stable
Fedora releases with that package set installed."
Further, a note for that says: "This criterion applies to the
recommended upgrade mechanisms only."
And per:
https://docs.fedoraproject.org/en-US/quick-docs/upgrading/
Only Gnome Software is "recommended" for Workstation. All other Fedora
editions and variants, dnf is recommended. Practically I think we'd
probably block on dnf system-upgrade bugs because chances are any
breakage on Workstation will affect other Fedora products. But if it
were true that a bug only affected Workstation and no other Fedora
product; and also the bug didn't happen with Gnome Software, would we
block? Hmmm. Entertaining.
--
Chris Murphy