Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system

[Rich Freeman]

On Wed, Nov 3, 2021 at 1:14 PM Ulrich Mueller <ulm@g.o> 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