On Mon, Jan 2, 2023 at 7:48 AM m1027 <m1...@posteo.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
