On Mon, Oct 19, 2015 at 4:38 PM, Richard Brown
On 19 October 2015 at 21:14, Claudio Freire
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@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org