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)

I would put gnome in the same bucket as Mesa, though. So your
experience, I'd say, is heavily biased towards the "not worth the
effort" portion of packages.

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
livelihood.

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
dependability.

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 :)

Lets hope the transition from 42.1 to 42.2 holds to your expectations.
If it does, I'll probably turn to your side.

For now, in my experience, the one from 13.1 to 13.2 didn't, because
of the same reason I already pointed out: such a wholesale update
updates more packages than you need. If everything's silk-smooth,
that's great. But things rarely are silk-smooth. OpenQA only does
basic testing, you'll have to recognize, some things depend on people
testing, and some use cases get none of that.

Maybe addon repos are only for knowledgeable users, since I happen to
be one of those, and I prefer a small, known set of potential problems
(up 1 package), to an unknown, potentially large set of problems
(dup). It does hinge on me being able to predict that first, small set
of potential problems, so it does require knowledge.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx