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

[Peter Stuge]

m1027 wrote:
> Wow, wasn't aware of catalyst at all. What a beast in terms of control.

It's not so well-known maybe because it was created by and for
gentoo-releng but if you know what you want it's a fantastic tool.


> (FYI: I enjoyed the links on catalyst you sent me directly.
> Unfortunatelly I cannot answer you directly due to the default
> TLS guarantee

Thanks! Glad you liked them. And yes, TLS is on my list.


> While being able to build exact environments with catalyst I wonder
> how it could help fixing the issue of my original post.

Thank you for connecting back to the original post! Let's see:


> Whenever we need to deliver a updated app to customers whose OS is
> too old (but updating it is too risky), we could either
> a) keep evenly outdated dev build OSes around forever (oh no!), or
> b) post our newly built app in a container (leaving the lovely native
> world); and both ignore the fact that customers wish maintenance of
> the entire OS actually, too.
> So, ideally, there is c): In a hypothetic case we would prepare a
> entire OS incl. our app (maybe via catalyst?) which would require
> a bootloader-like mini-OS on the customer's side, to receive updates
> over the internet, switch the OS at boot time, and fallback.

I had a) in mind. Why "oh no!" ? I didn't mean forever.

I think it's already a very good value proposition that you can deliver
updates of your apps for the particular systems that your customers run.

catalyst building specific, "old-like" OSes on which you build new (binpkg)
versions of your app to be installable by emerge on old customer OSes is
admittedly a lot of work, at least initially.

Separate from those app updates you can then use catalyst to also tackle
OS maintenance/updates. You can create either full milestone OSes or just
individual (binpkg) packages through which customers' OSes can become
less fragmented over time, at the pace each customer is comfortable with.
OS updates can take only small steps at a time, since catalyst allows
exact control.

This could reduce target OS diversity drastically over time with probably
relatively moderate development effort. More effort might go into holding
customer hands along the bespoke update paths.

So, I see controlled paths forward in both problem dimensions. I don't
know if the effort is actually practical for you but it /is/ doable and
most importantly it can be customized for the individual systems
currently in production at your customers.


//Peter