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
