On Wed, Nov 3, 2021 at 1:14 PM Ulrich Mueller <u...@gentoo.org> wrote: > > >>>>> On Wed, 03 Nov 2021, John Helmert wrote: > > >> | https://projects.gentoo.org/council/meeting-logs/20091109-summary.txt > >> | > >> | Upgrade path for old systems > >> | ---------------------------- > >> | Vote (unanimous): The ebuild tree must provide an upgrade path to a > >> | stable system that hasn't been updated for one year. > > > Does "upgrade path" imply a simple world upgrade is all that should be > > necessary to upgrade the system? I wouldn't interpret it this way. > > That a "simple world upgrade" was meant is very clear from the full > meeting log, and from the log of the previous 2009-10-12 meeting (open > floor section). >
It probably would be good to get these policies documented someplace OTHER than the council decision logs. I do remember the discussion from the distant past but it is worth having it in a more prominent place, especially since a one year stable update path is not going to happen by accident. I was thinking that it matters way more that @system is updatable than world in general, since @system can be used to bootstrap everything else. However, I think this distinction really doesn't make much of a difference. If your system can't be smoothly updated, it is unlikely to be due to some leaf package like a browser/MUA/etc. Most likely it is due to a widely-used dependency. So, by all means require @world to be updatable, but I think that if you focus on the packages in @system you'll basically get the rest for free. EAPI 8 came up in a later email and to consolidate replies I'll just say that the issue isn't so much adopting EAPIs in newer packages, but the rush to tidy up old ones that creates the problems. If you have v1/2/3 of a package stable and in the repo, and v3 uses an unsupported EAPI, and v1 is installed, I think portage will (or at least ought to) offer an upgrade from v1 to v2 - it should just not see v3 or consider it in the depgraph. Of course keeping around old versions might require dealing with security issues/etc that impact them. An alternative would be of course to just avoid EAPI updates on @system for a little while, or at least the parts of @system that portage needs to upgrade. Having QA tools detect this would be ideal, but right now they could only reliably detect things like newer EAPIs in @system. Since we don't require putting @system dependencies in packages there is no way for a QA tool to tell what is or isn't needed to update portage. Then you have more complex situations like PYTHON_TARGETS, and probably others as well. I had one host that struggled a bit with the xcrypt update for some reason (some weird preserved libs issue or something - libcrypt was still showing up as owned by glibc after updating it and I had to override collisions to get xcrypt to install). When upgrading a system that is completely up to date requires careful following of news items it is going to be painful to execute a whole bunch of updates at once. Maybe another path would be to mark milestone repositories for the last year that are easy to update in sequence. So if you have an update that requires manual care, you could mark a milestone just before that update which is easy to get to, and then another one after the update (ideally right before the next difficult update). This would just be a snapshot of portage or a git commit reference, and along with that a commitment to maintain distfiles/etc if they aren't hosted in reliable places (ie patches/etc in devspace). Another option might be to have collections of binary packages at key milestones. Sure, they won't be built to a user's specification, but if you have a year old system you could use them to quickly bootstrap it up to something more recent, and then an emerge will rebuild anything that has the wrong USE flags/etc and to bring the system completely up to date. You could even just use those binary packages as a sort of release-based version of the distro. Just some things to consider. -- Rich
