On 03/08/2018 01:39 PM, Neal Gompa wrote:
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.
It's not a solution because doing so usually drags half the distro along
due to library dependencies etc.
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.
No, preupgrade & friends basically created a special boot target that
runs the whole thing with the new version, in an isolated environment.
Which equals "using the target rpm stack" in fact.
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.
That's quite a different thing, and creates it's own quirks and issues.
And it doesn't help things at all when the simple "dnf update rpm dnf"
drags along for example a new glibc or python version which snowballs
into 70% of the distro getting pulled into the "just update rpm"
transaction.
- Panu -
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
