On 05/01/2023 12:09, m1027 wrote:
frederik.pfautsch: > >>> 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,
frederik.pfautsch:
> > 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
peter:
> > 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);
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
Hi,
On Mon 02 Jan 2023 23:31:17 GMT, m1027 wrote:
> I am not complaining here. Hey, we are on rolling release. Some of
> you may even know individual solutions to work around each of it.
> However, we just may get into trouble when distributing newly
> compiled apps (on new Gentoo systems) to
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
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
On Mon, Jan 2, 2023 at 4:55 PM m1027 wrote:
>
> Many thanks for your detailed thoughs for sharing the rich
> experiences on this! See below:
>
> antarus:
>
> > On Mon, Jan 2, 2023 at 4:48 AM m1027 wrote:
> > >
> > > Hi and happy new year.
> > >
> > > When we create apps on Gentoo they become
Many thanks for your detailed thoughs for sharing the rich
experiences on this! See below:
antarus:
> On Mon, Jan 2, 2023 at 4:48 AM m1027 wrote:
> >
> > Hi and happy new year.
> >
> > When we create apps on Gentoo they become easily incompatible for
> > older Gentoo systems in production where
sam:
> > On 2 Jan 2023, at 12:48, m1027 wrote:
> >
> > Hi and happy new year.
> >
> > When we create apps on Gentoo they become easily incompatible for
> > older Gentoo systems in production where unattended remote world
> > updates are risky. This is due to new glibc, openssl-3 etc.
[...]
>
On Mon, Jan 2, 2023 at 4:48 AM m1027 wrote:
>
> Hi and happy new year.
>
> When we create apps on Gentoo they become easily incompatible for
> older Gentoo systems in production where unattended remote world
> updates are risky. This is due to new glibc, openssl-3 etc.
I wrote a very long reply,
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
Hi,
m1027 wrote:
> So, what we've thought of so far is:
>
> (1) Keeping outdated developer boxes around and compile there. We
> would freeze portage against accidental emerge sync by creating a
> git branch in /var/db/repos/gentoo. This feels hacky and requires a
> increating number of develper
> On 2 Jan 2023, at 12:48, m1027 wrote:
>
> Hi and happy new year.
>
> When we create apps on Gentoo they become easily incompatible for
> older Gentoo systems in production where unattended remote world
> updates are risky. This is due to new glibc, openssl-3 etc.
>
> So, what we've thought
On Mon, 2023-01-02 at 12:48 +, m1027 wrote:
> Hi and happy new year.
>
> When we create apps on Gentoo they become easily incompatible for
> older Gentoo systems in production where unattended remote world
> updates are risky. This is due to new glibc, openssl-3 etc.
>
Just update them.
On Mon, Jan 2, 2023 at 7:48 AM m1027 wrote:
>
> When we create apps on Gentoo they become easily incompatible for
> older Gentoo systems in production where unattended remote world
> updates are risky. This is due to new glibc, openssl-3 etc.
So, unless you're proposing some improvement this
Hi and happy new year.
When we create apps on Gentoo they become easily incompatible for
older Gentoo systems in production where unattended remote world
updates are risky. This is due to new glibc, openssl-3 etc.
So, what we've thought of so far is:
(1) Keeping outdated developer boxes around
17 matches
Mail list logo
