Re: [gentoo-dev] Gentoo LTS or: proper backward compatibility?

[Rich Freeman]

On Mon, Jan 2, 2023 at 7:48 AM m1027 <m1027@××××××.net> wrote:
>
> When we create apps on Gentoo they become easily incompatible for
> older Gentoo systems in production where unattended remote world
> updates are risky. This is due to new glibc, openssl-3 etc.

So, unless you're proposing some improvement this might be
better-suited for the -user list.  Officially Gentoo doesn't really
"support" a stable/LTS/release-based environment.  That isn't to say
that it couldn't be made to do this, however, a more release-based
process is one of the core competencies of most other distros, so I'm
not sure how much Gentoo would add here vs just running something
else.

> (1) Keeping outdated developer boxes around and compile there. We
> would freeze portage against accidental emerge sync by creating a
> git branch in /var/db/repos/gentoo. This feels hacky and requires a
> increating number of develper VMs. And sometimes we are hit by a
> silent incompatibility we were not aware of.

If you're running a large production environment and want a stable
platform to target, I'd think you'd want to minimize the number of
those you have.  You wouldn't want every server running a different
base OS, and then have a branch to target development at it.

The idea of basing your own releases on Gentoo is probably something
many companies do.  All you need is to just host one repository and
distfile mirror for it, and point all your production hosts at it.
Then you could have staging/development environments, and promote the
core OS as appropriate.  Then your migration path is the same for all
hosts and you can account for major vs minor changes.

You do need to mirror distfiles as one of the weaknesses of Gentoo for
a release-based strategy is that we do not have a solid solution for
archiving things like patches/services/etc that are distributed
outside of the repo.  If a package is removed from the current repo no
QA process ensures that the SRC_URIs for anything they used remain
stable.

Of course somebody would need to do the work but it shouldn't be THAT
difficult to have a Gentoo Reference Release project that basically
just snapshots the repository/distfiles at points in time and provides
a guarantee of clean updates between milestones.  Of course if you
want backported security updates on top of that this would be quite a
bit more effort.  It would mainly be useful for those who aren't
updating regularly, but completely ignoring all updates isn't a good
practice regardless which is probably part of why this hasn't
happened.  You could greatly minimize the cost of backporting security
updates if you only targeted packages of interest to you, or where the
updates are low-risk to you, but that depends quite a bit on your own
needs.

> (3) Distributing apps as VMs or docker: Even those tools advance and
> become incompatible, right? And not suitable when for smaller Arm
> devices.

I don't see why containers would be unsuitable for ARM.  VMs certainly
are memory hogs but well-designed containers don't really consume much
more memory than the service they are hosting.  Of course if you dump
a whole OS in a container that will consume a fair bit of RAM.

An advantage of containers is that they make the host OS less
relevant.  You could run a release-based distro with security-only
updates on the host, and then application containers are low-risk to
update remotely and can be built in whatever environment they are most
suited to.

There is a reason k8s is popular.

-- 
Rich