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).
OpenPGP_signature
Description: OpenPGP digital signature
