Mailinglist Archive: opensuse-factory (1324 mails)

< Previous Next >
Re: [opensuse-factory] Will we have additional repositories for Leap as we have currently?
On 19 October 2015 at 21:14, Claudio Freire <klaussfreire@xxxxxxxxx> wrote:

While addon repos have indeed been dodgy regarding stability, they
have been very valuable, so your assessment seems quite nearsighted.

Yes, it's difficult to make them hold to the same standards as stable
distributions. But unlike rolling distributions, you don't have to
risk your whole system (and time) to update some component you
absolutely need.

I'd argue my opinion isn't nearsighted, I'm speaking from the school
of experience.

I've seen it both as a user and as a maintainer.
I've done the 'rolling stuff ontop of a stable base' as a user of old-Tumbleweed
I've been part of the team that built repos for that scenario with
GNOME:Stable repos (which I also used)

and in both cases, despite my best efforts, neither got anywhere NEAR
the level of quality and reliability that Tumbleweed is at, today, and
every day

as for the risk - with openQA protecting me before the point of
distribution, I've never experienced breakage like I did with pre 2014
Tumbleweed or even with openSUSE+GNOME:Stable.

And even with that in mind, with snapper + btrfs + grub2 boot from
snapshot ALWAYS giving me a 'get out of jail free' option on my own
machines, there really is no risk.

Why put extra effort into creating additional repos for latest
software on Leap when we already have the _best_ option for that use
case in Tumbleweed?

'It just works', it's been 'just working' for me for over a year now,
and if there is ever a moment that it doesn't, I can roll the whole
thing back to the last time that 'it just worked' and then know that I
have a very strong, fast, reliable community who will help me get the
issue fixed bloody quickly, and then implement tests to make sure it
never happens again.

(NOTE: The only time I've needed to use btrfs snapshots in the last 14
months on running Tumbleweed on all of my machines was due to user
error where I accidentally tried to delete the majority of the
contents of my root partition.

So we have unequivocal proof that I'm more dangerous to my own machine
than any of the updates we've rolled out to Tumbleweed in the last 14

Furthermore, you won't know you need the addon repo until after you
installed and have been working with the distribution for a while.

Say you install Leap, and it's fine because at that point everything's
the latest or close enough. Let a year pass, and while you got all the
security updates, you start noticing that this annoying little bug in
software X just became a showstopper for you, and see that a newer
version has it fixed. Software X is a leaf package, so you think: I
should just update it, but yeah, it depends on libY and libZ. Still,
nothing else uses libY, and the libZ update is binarily backwards
compatible, so you update, and live happily ever after.

Sure, it's tricky, you can actually break things. But the nature of
the breakage is far more limited and predictable than in the case of
tumbleweed's "zypper dup", which simply by following the mailing list
can be scary to watch if you actually depend on your computer for your

Add to that the fact that people will simply wash their hands if you
use TW and don't dup (updating a single package? you're on your own),
and you can start to appreciate the value of addon repos.

So, I agree, addon repos for core components (say Mesa) would probably
be too much effort to be worth it. But that's not something you can or
should generalize. Leaf packages should be just fine.

I love this example, because it actually feeds into something that I
expect to see with Leap's future development

Lets imagine this situation, where something with Leap 42.1 is a
little on the rough side, and could be fixed by updating the package

In 1 years time (possibly a little earlier) Leap 42.2 will be out. In
this scenario, that update that you want of a leaf package, shouldn't
be thrown in some random repo, but be submitted as part of 42.2.

This theoretical example is a perfect example of the kind of thing the
'minor versions' of Leap are intended to address, but in that case,
the minor versions will be tested, polished, tested again, integrated,
and polished some more as one consistent upgrade for 42.1

Leap should be something people can put their faith into, the
development model we have for Leap ensures that, while the lifecycle
we have for Leap means that we'll have annual opportunities to take
care of issues just like the one you raise above.

The Frankenstein monsters created by throwing together random
collections of disjointed repositories are never going to measure up
against Leap or even Tumbleweed when it comes to reliability or

So why expend the additional effort?
Lets focus on the core problems, getting our two main distros, Leap
and Tumbleweed, as good as they can be, for the use cases they exist
to address :)
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >