peter:

> Peter Stuge wrote:
> > Essentially you will be maintaining a private fork of gentoo.git,
> 
> If this seems too heavy handed then you can just as well do the reverse:
> 
> Maintain an overlay repo with the packages you care to control in the
> state you care to have them, set that in the catalyst stage4.spec
> portage_overlay and add unwanted package versions in gentoo.git to
> the package.mask directory used by catalyst.
> 
> This may sound complicated but it isn't bad at all.
> 
> For total control also make your own profile, e.g. based on embedded,
> but that's not per se neccessary, only if the standard profiles has too
> much conflicts with what you want in @system.
> 
> catalyst will rebuild @system according to spec file but with too much
> difference that just becomes annoying and feels more trouble than a
> controlled profile.
> 
> This approach falls somewhere between your options (1) and (5).

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.

Thanks


Reply via email to