Ruediger Meier schrieb:
[...]
What use cases would you use it for which Leap couldn't do?
I want a distro where self-built binaries don't break because of maintanance upgrades. This point is my most important point speaking as sysadmin. I don't want that my (mostly very advanced) users hate me.
Maintenance updates are maintenance updates and I agree that the goal there is to avoid breakages as much as possible. For service pack level upgrades like from 42.2 to 42.3 some issues are expected. We need to have some degree of freedom and make compromises there.
Also I want "source-compatibility", I mean that a software which builds fine on 42.1 should still build on 42.3. The best test for this is the OBS repo aleady. It should not be allowed that one packager breaks the package of another packager. Think about developers using Leap as CI build host.
That is certainly desirable but sometimes it just doesn't work out. Even maintenance updates sometimes come with a surprise. Who would have guessed that an undoubtedly mandatory update of the timezone database breaks build of other packages for example?
Would this mean reducing the scope of Leap?
IMHO this would be exactly what I thought Leap is supposed to be. Moreover I would say this would make the scope bigger.
Regarding the unhappy people who want more the newest stuff. IMO we should keep an eye of making more packages able to be installed in several versions in parallel, so that pulling from 3rd party repos is less painful.
I agree to that. We already to that for gcc or boost for example. There's a default system version but newer versions are also available.
Would you be willing to contribute to/release manage/help maintain/support such a distribution?
Yes, of course. On the other hand I will not provide any build fix anymore for current Leap, for example my sbcl package. This is waste of time IMHO.
You are asking for at least two things: 1. a package must not break build of another packages 2. packages must not be dropped I have to add 3. packages that don't build can't be shipped So unfortunately the texlive update caused a build failure in one of 9600 packages. From my perspective that's a quite smooth experience :-) It doesn't look like a vastly incompatible texlive. So please think about your sbcl users that want to have it in 42.3 too. At least analyze the cause of that failure. Could be an intentional or accidental incompatible change in texlive, could also be a bug or misuse of undocumented features in sbcl after all. This time it hits you with some build failure, next time someone else doesn't get the desired package update. Doesn't bring us anywhere to feel offended. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org