On 03/08/2018 02:23 PM, Neal Gompa wrote:
On Thu, Mar 8, 2018 at 6:48 AM, Panu Matilainen <pmatilai@xxxxxxxxxx> wrote:
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.
I suppose part of this is because the way we package libraries makes
it so that new library packages _must_ replace older ones as sonames
change. In Mageia and openSUSE, it doesn't work like that at all.
You'll get your new library dependencies for the RPM stack and then it
would re-execute with that target, and then upgrade the remainder of
the system.
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.
In my mind, that's functionally equivalent. Yes, it's not actually on
the target yet, but it operates under the newer rpm environment.
This sounds like there's supposedly a disagreement somewhere in there
but I don't know what it is. Details about how exactly preupgrade and
friends went about their business maybe, but ultimately they did exactly
what is being discussed: run the upgrade transaction on the target
stack, because they created/downloaded/whatever a minimal environemnt
from which to chroot-upgrade the actual root. That is *the* generic
solution to this whole thing. Clearly there was something wrong with
preupgrade & all or they wouldn't have been abandoned, but they did that
one thing right.
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.
New glibc versions by itself should not snowball into 70% of
distribution, otherwise something is broken with how the dependencies
are versioned.
As for pulling in a new Python, you're right that it's an issue, but
it's an issue no matter what. Even when it's in the same transaction,
it's all broken until everything is upgraded anyway. And if we're
talking about this being done with system-upgrade or dist-upgrade
commands, then we can reasonably expect that we can upgrade a subset
first, then restart DNF with the new stack, and pass in the remainder
of the transaction to complete.
That said, stuff like this with the Python stuff makes me think we
should have pythonX.Y-foo packages that have Obsoletes/Provides
pythonX-foo instead, so that stuff wouldn't actually break like this.
But that's another discussion...
And also, PackageKit offline upgrades wouldn't be affected by the
Python bit and could happily do this "properly", if the Python bit is
what you're worried about.
Python is just one example, PackageKit (like almost everything) has
their non-trivial dependencies that also snowball.
>
Another way to solve that problem would be to have a minimal C/C++
implementation that DNF would hand off to for system upgrades to avoid
the Python issue. Personally, I don't think that's necessary, all
things considered, but it's an option.
But I think we *really* should have the splitting transactions
feature, not just for system upgrades, but for dealing with a litany
of conditions that may make it difficult to do "big" transactions.
And all that is somehow easier than doing the right thing and setting up
a minimal environment with the new stack from which to run the transaction?
Oh well, told 'ya they wouldn't listen to us old goofs ;)
- Panu -
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
