Slowroll advice

[Roger Oberholtzer]

We have always used kiwi to make OEM images of leap releases. This has
always worked beautifully. Systems running these OEMs do not get
changed at the OS level. We make OEM images relevant Leap version. And
usually just one OEM image for each. So we don't have that many
targets to build for. Only our software gets updated. By design. We
make a TAR archive (via kiwi) of all the needed development tools and
whatnot when we make the OEM image. This archive is used in a chroot
jail so we can build for the OEM target independent of whatever the
local Linux system might be running. It's a great setup.

The only downside to this is that Leap has an end of life. So we
occasionally find ourselves needing to do a fresh install of the OEM
images every couple of years, Granted this is not a major issue. But
at the same time, due to the complexity of the systems, it is an
involved task.

I am looking to see what alternatives might exist. Like slowroll. I
see messages about building OEM images of slowroll with KIWI. Does
this work similar to when building a Leap image? That is, can I use
various repositories and install packages as I would for Leap? I am
guessing that there are slowroll-specific repositories. If so, are
they generally enabled on OBS?

Another question is perhaps a bit outside kiwi, but I thought I'd ask.
How often must you do updates of slowroll? Our systems are often
involved in contractual measurements. These often require that we do
not change things for the duration of the contract. So we would do
updated perhaps once a year. I realize that this is not so often. But
that's our reality. Is slowroll a good choice in that case? Or might
there be a better approach to all this? Any suggestions or experiences
are welcome.

I personally run tumbleweed on my development system, and build for
various OEM targets via the chroot jail I mentioned above. So I know
the issues with library versions in these kinds of systems. Striking a
balance between ease of update and stability of libraries and such
seems to be quite a sport.

--
Roger Oberholtzer

[Marcus Schäfer]

Hi Roger,

> The only downside to this is that Leap has an end of life.

Like every non rolling release distro ;)

> I am looking to see what alternatives might exist. Like slowroll. I
> see messages about building OEM images of slowroll with KIWI. Does
> this work similar to when building a Leap image?

Yes in basically the same way, just the repos are different

> That is, can I use
> various repositories and install packages as I would for Leap?

just one repository because you would be moving to the SUSE
rolling release called TumbleWeed. So the repo for Slowroll
would be:

https://download.opensuse.org/repositories/openSUSE:/Slowroll/standard/

Or some ftp sync. Useful information can also be found here
https://en.opensuse.org/Portal:Slowroll

> I am
> guessing that there are slowroll-specific repositories. If so, are
> they generally enabled on OBS?

I'm only aware of the kernel project that has its own Slowroll
variant. But you are right that there might be project specific
Slowroll variants for projects serving the TumbleWeed distribution.
However, when using TW I would only use one repository that has
it.

> Another question is perhaps a bit outside kiwi, but I thought I'd ask.
> How often must you do updates of slowroll?

So TumbleWeed changes every day, Slowroll changes every month

> Our systems are often
> involved in contractual measurements. These often require that we do
> not change things for the duration of the contract.

I don't think that a rolling release is the right candidate in this
case unless you take a snapshot of slowroll into your own company
network and build the image from there. In this case you can decide
yourself for the cadence to sync slowroll. If you consider to
do this you could also use TumbleWeed as there is then no difference.
My general recommendation for people using rolling releases is
that they should first invest in a sync process that meets the needs
of the company and build their images based on this data and not
on the data provided by the distributor because those typically
changes every day and even a monthly cycle is in most cases
not appropriate for stable customer workflows. But this is just
my opinion.

> So we would do
> updated perhaps once a year. I realize that this is not so often. But
> that's our reality. Is slowroll a good choice in that case? Or might
> there be a better approach to all this? Any suggestions or experiences
> are welcome.

See above

> I personally run tumbleweed on my development system, and build for
> various OEM targets via the chroot jail I mentioned above. So I know
> the issues with library versions in these kinds of systems. Striking a
> balance between ease of update and stability of libraries and such
> seems to be quite a sport.

I fully agree and I'm not using rolling releases for my workstations
because of that. Maybe I'm old school in this regard but I like the
cadence the Fedora project has with their release cycles. SUSE had
something similar in the past and I found it sad that they did not
continue providing stable releases. For SUSE public you actually
can choose between Leap and TW. Leap is SLES+backports and TW is
the rolling release. There is a big gap between them

Hope this helps

Regards,
Marcus
--
Public Key available via: https://keybase.io/marcus_schaefer/key.asc
keybase search marcus_schaefer