On 3/28/20 8:59 AM, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Mar 27, 2020 at 10:34:49AM +0200, Panu Matilainen wrote:
On 3/27/20 9:55 AM, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Mar 27, 2020 at 09:04:53AM +0200, Panu Matilainen wrote:
On 3/26/20 2:35 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Mar 26, 2020 at 02:00:49PM +0200, Panu Matilainen wrote:
previous-release-blocker(s) and previous-previous-release-blockers(s),
since the changes would need to be deployed in F32 and F31. Also
note that the last time when the upgrade plugins run code is in
upgrade phase between two reboots, and the plugin is running
pre-upgrade code. This code would then invoke post-upgrade rpm. It's
certainly doable, but seems a bit funky.
Right, requiring changes to previous versions is not okay. I seem to
be thinking our upgrade tooling had gotten fixed at some point to
perform the upgrade on the target distro packaging management stack
as it would really need to be, but guess that was just a dream.
Relying on the target distro management stack sound nice, but is
actually problematic: how do you run the next version before you
install the next version? Sure, you can install stuff to some temporary
location and run the tools from there, but then you are running in
a very custom franken-environment. Such a mode of running would face
the same issue as anaconda installer: it would only get tested during
the upgrade season, languishing otherwise.
Mock has this cool bootstrap image thing now. It seems to me we
could use that image to run the system upgrades too [*]. And if/when
we get koji to use that, it'll solve a number of ages old problems
on the build system, AND that image will get heavily tested 24/7 so
it wouldn't be any once in a full moon franken-thing.
[*] Mount the host filesystem from mock and perform a dnf
--instalroot=... distro-upgrade on that, turning the whole landscape
inside out.
Where would mock be executing from? The same filesystem it is modifying?
Where is the offline upgrade executing from? How's this
fundamentally different?
It's not — the point I was trying to make that IF we are running from
the the host filesystem, it is easier to run directly from it.
Easier? Sure, upgrades are hard, lets go shopping.
This subject has a long history of different approaches. Things that
are more like what you describe than what we're currently using have
been used in the past. And at least for Fedora, it seems that the
simplicity of the current approach wins over the limitations.
For RHEL the best solution may need to be different.
Oh come on. Running from a bootstrap image allows using full native
capabilities of rpm/dnf in any new version, without having to
consider what the previous versions support. How's that "not much"?
Yes, that is an important hurdle that Fedora generally doesn't encounter
at all. Fedora usually waits until the new rpm functionality is released
in older versions of Fedora before allowing it to be used in rawhide.
I think this should be a viable approach for RHEL too — after all, rpm
is very good at keeping backwards compatibility.
No. This isn't about *backwards* compatibility, this is about *forward*
compatibility, which places terrible limits to what features can be used.
RHEL 7 was released in 2014. RHEL 8 came out in 2019. In the meanwhile,
Fedora had started using file triggers and rich dependencies because it
could - and why not. But RHEL 7 rpm hasn't got a chance of dealing with
those. So if you bring the waiting strategy into RHEL world, people
could only start using file triggers and rich dependencies in RHEL and
EPEL 9 which I can only assume will be released some year in the future.
Think about that for a while.
In other words, that puts a better half of a *decade* between a feature
being introduced in rpm to when it could be actually used in a RHEL
release. And an even bigger gap of what can be done in RHEL and Fedora
than it is now, as in: extra burden on maintainers. "Easier" has little
to do with this all.
I'm sure rpm can be blamed for this in part - we don't introduce
features with new rpmlib() dependencies often enough that people drift
into this "yessss we can waaiiiit another yeaaar" mode. And then they
snap out of it when the upgrade tooling fails because of new rpmlib()
deds, at which point its already a year too late so save it for that
release.
Another approach could be to perform the upgrade in two steps: have
a rpm+dnf stack compiled for the old version, install it, and then
do the upgrade to the real target version. Dunno, that's quickly
getting complex.
This isn't feasible as the stack might not even be compilable on the
previous release due to other version differences. Yes, upgrades are hard.
- Panu -
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
