On 03/07/2018 03:10 PM, Neal Gompa wrote:
On Wed, Mar 7, 2018 at 5:52 AM, Igor Gnatenko
And you forgot:
5. Teach DNF to use "target" DNF/RPM stack to perform upgrade (best and
This has been requested for a long time:
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
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 -- email@example.com
To unsubscribe send an email to devel-le...@lists.fedoraproject.org