On Thu, Mar 8, 2018 at 2:53 AM, Panu Matilainen <pmatilai@xxxxxxxxxx> wrote: > 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. > > 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. > You're right in that upgrading rpm + dnf + libsolv first won't fix it 100% of the time (mainly with features that can't be guarded by rpmlib() dependencies, such as the new header size), but I think it'll deal with more than 80% of the cases where we have a problem, such that distribution upgrades through this mechanism will work as we introduce new features in the distribution. But I would disagree that updating rpm + dnf first is not a solution at all. It's not a *perfect* solution, but it would help a hell of a lot more. Hell, even preupgrade and older mechanisms more or less worked by getting the target rpm and package manager code installed first and then doing the real thing using that code. And supporting transaction ordering such that transactions can be broken up into smaller ones as needed based on various conditions would make upgrades more reliable in general, in my opinion. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
