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

[Frederik Pfautsch - fpprogs]

Am 04.01.23 um 23:00 schrieb m1027:

>
> Wow, wasn't aware of catalyst at all. What a beast in terms of
> control.
>
> (FYI: I enjoyed the links on catalyst you sent me directly.
> Unfortunatelly I cannot answer you directly due to the default TLS
> guarantee kicked in by my provider: "TLS is required, but was not
> offered by host". That's usually to be fixed on the receiving side.)
>
> While being able to build exact environments with catalyst I wonder
> how it could help fixing the issue of my original post. To sum up:
> 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 was recently playing with systemd-boot
> and it's interesting try-boot feature.


So essentially it sounds like you want something similar to Yocto / Poky 

/ Petalinux for the non-embedded world (and based on Gentoo of course; 

it sounds like catalyst is something like that)?



Petalinux / Yocto is essentially a cross compiling environment with 

rootfs, etc. And after everything has been built, the rootfs is just 

packaged into a flashable ext4-image or something. So your devs wouldn't 

need to work on a (slightly) outdated system, just use the (in this case 

non-)cross-compiling environment with its own, separate rootfs. Is, 

e.g., crossdev able to build a non-cross, native compiler? It already 

provides a rootfs-folder and a separate emerge-config, etc...



Just throwing crazy ideas around, what about using net-boot for your 

customer? This way they just need to store an image somewhere and can 

update it whenever necessary. Or (ab-)using an initramfs. Or u-boot 

bootloader, just like in the embedded world. Depending on the size of 

the actual OS/rootfs, taking ideas from e.g. Android with their A/B 

bootslots (i.e. two root-partitions or something, where one is active 

and the other can be updated with clever scripts, after a reboot they 

are swapped).