On Wednesday 27 of May 2015 00:15:31 Christian Boltz wrote:
What about updated core packages?
AFAIK SLE 12 ships with AppArmor 2.8.x which isn't supported upstream anymore, and has totally different code in the aa-* tools (2.8 has perl tools, 2.9 got them rewritten in python, so backporting fixes is basically impossible - and the SLE maintainers already found this out the hard way [1]).
I'm quite sure I'll submit AppArmor 2.9.x(or the soon-to-be-released [2] 2.10) to openSUSE 42 because maintaining 2.8.x would be a pain. Needless to say that this comes with more changes than just the aa-* tools, and might influence other packages in the core.
IMHO in the end it will always be up to the package maintainer(s) to decide if the benefits (both functional and maintenance) of newer package version outweigh losing the easier life of consuming SLE updates. (For leaf packages, that is. For packages others depend on, interest of those will have to be taken into account.)
If the bug affects SLE package and there are no obvious reason not to, I suppose the fix would be included in SLE as well.
Nice if condition ;-)
What happens if the bug is caused by a package that was updated in openSUSE 42, but not in SLE? (The above example shows that this is something that can happen in practise.)
I have a problem with the construct of "a bug in package A caused by package B". I suppose you what you really mean is a bug in core package A that didn't manifest until non-core package B was used with it". I'm afraid there can't be a general rule for this. It will always depend on seriousness of the bug, intrusiveness of the fix and some other factors. After all, we (1) often fix bugs in SLE packages that need third-party software to manifest and (2) sometimes don't fix acknowledged bugs (even those not requiring any extra SW to manifest) with known fix if there are good reasons not to. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org