[PureOS] Bits from PureOS | Sharks!

Matthias Klumpp matthias.klumpp at puri.sm
Mon Aug 5 10:11:27 PDT 2019


Am Mi., 31. Juli 2019 um 17:09 Uhr schrieb Jeremiah C. Foster
<jeremiah.foster at puri.sm>:
>
> On Wed, 2019-07-31 at 13:22 +0200, Matthias Klumpp wrote:
> > [...]
>
> Fair point.
>
> > (that's why we either need to find a way to do that automatically,
>
> While this approach is tempting, there be dragons.
>
> >  or
> > just keep green rolling and create a new stable suite that existing
> > users can opt-in instead)
>
> I'm starting to feel this may be the best alternative. I do worry that
> there will be a flood of packages coming in however it we go down this
> path - can we manage that?

The "make new stable suite" is my preferred solution, as it is
relatively simple, clean and most importantly very safe to do. We can
absolutely handle a massive influx of packages from Debian into green,
that's no problem.
I would create the "amber", "amber.updates" and "amber-security"
suites, populate the amber suite with the stuff that's in green,
change the distribution release ID for the stable suite in the stable
suite (amber) only, adjust the image builder to recognize the new
suite and create a few images for that suite. Then we can tell our
users to switch to amber now if they want stable or remain on green,
and then after a week open the floodgates and sync up green with
testing again.
New Librems would then ship with amber by default.

In the long run, "green" would be an alias for the next development
suite, probably some color starting with "b" ^^

It's quite a bunch of work, but at least nothing will break in the
process. The only downside is that existing user of green who don't
opt into stable in time will remain on the development branch. But I
don't see a non-hacky way to move them to a different branch
automatically, and changing green to not mean "rolling release" is
tricky.

Cheers,
    Matthias


More information about the Pureos-project mailing list