On 19 October 2015 at 21:14, Claudio Freire
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 months)
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 :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org