Re: Broken system upgrade due to rich dependencies

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

 



On 03/07/2018 03:10 PM, Neal Gompa wrote:
On Wed, Mar 7, 2018 at 5:52 AM, Igor Gnatenko
<ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote:
And you forgot:
5. Teach DNF to use "target" DNF/RPM stack to perform upgrade (best and
proper way).


This has been requested for a long time:
https://bugzilla.redhat.com/show_bug.cgi?id=1032541

It'd be *really* good if DNF implemented it.

That's quite an understatement.

It's rpm's responsibility to keep track of its features. If things had been the way they're supposed to be, rpm would've simply *prevented dnf* from doing this upgrade-gone-bad. And now let the implications of that sink in for a moment.

Rich dependencies are tracked with an rpmlib() dependency, however that didn't get adjusted for the new dependencies introduced in 4.14, they just slipped through reviews without any of us noticing. So it's a bug in rpm, and kinda hard to fix after the fact because all those packages that would need the tracking dependency are already out there.

A handful of mishandled dependencies is one thing. A change like switch to different payload compressor is something quite different, you just could not upgrade no matter how much you wanted to. And now, let the implications of THAT sink in for a moment.

New rpmlib() dependencies occur every now and then, but since it's not a monthly event people keep forgetting. Happens predictably every time. And judging by me hardly recognizing any names on the DNF team, there's so much new blood on board that they might not even know this in the first place.

Bottom line: either dnf (or something else) grows an dist-upgrade method that runs the transaction on the "target stack" OR Fedora is *forced* to hold back on new rpm package features until all the active versions have a rpm/dnf stack that can handle them. Period. No ifs or buts.

P.S. No, updating rpm + dnf first in a separate transaction is not a solution at all.

P.P.S. So why didn't yum have anything like that? Because back then, there were other upgrade methods that did run on the "target stack": anaconda, preupgrade, fedup to name a few.

	- Panu -
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [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