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 -