Ruediger Meier schrieb:
What use cases would you use it for which Leap
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
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?
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
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
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
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.
(o_ Ludwig Nussel
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org