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

[Sam James]

> On 3 Nov 2021, at 20:16, Rich Freeman <rich0@g.o> wrote:
> 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.

+1

> 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.

This isn't quite true because it's very possible that plenty of things
will have e.g. subslot deps on @system packages and therefore
are holding them back if a change happens (you want to rebuild
everything together).

> 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.

Right. I think we could really try to just not cleanup so aggressively
unless we know there's some nasty < dep in the ebuild.

There's another really good reason for this: stabilisation and such
doesn't catch everything, and you might find you just got upgraded
to a newly-stabled ebuild which doesn't work, and now you have
to fight to downgrade because cleanup was immediately done!

> 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.

(We did work very hard on this to make it as smooth as possible
and we've also dropped the workaround which caused the intentional
collision (which we mentioned in the news item + glibc's pkg_postinst)
which Portage should've ignored with default FEATURES b/c the file
was orphaned, but it should be better now.)

best,
sam