-----BEGIN PGP SIGNED MESSAGE-----
On 05/07/2015 01:39 PM, Bruno Friedmann wrote:
On Saturday 02 May 2015 00.26:23 Stephan Kulow wrote:
Am 01.05.2015 um 23:32 schrieb Wolfgang
If the project finally agrees to have something
more stable and
longer maintained and the approach of service packs every 12
And this is the key point. We have to decide for ourselves, what
we want to achieve with openSUSE releases. And if we go there, we
have to live with the consequences - i.e. accepting the patch
madness SLE packages can be.
Excuse my ignorance, being not that much impacted by SLE in my day
life. For making it clear to the community, I guess that some part
of what happen during a normal SLE cycle should be published, so
the community, knows what kind of consequences we would have to
What is madness? Updating a package (like kernel 3.0 introduction)
or never update something and increase its patch numbers until it
look like The Tower of Pisa?
The basic premise is that the underlying version does not change for
many years. Patches are applied to fix bugs (security and others) and
in the case of the kernel do hardware enablement.
Historically there were no version upgrades to packages that are
considered "core", period. Version upgrades to things outside of core
were rare. In SLES 11 that changed with the kernel being upgraded from
2.6.32 to 3.0.13 when SLES 11 moved from SP1 to SP2. There is lots to
read about that  if you care to.
So if we stick to the kernel as an example as this is probably the
most popular and was also picked on in other threads it amounts to the
fact that a few thousand patches may accumulate. One can describe that
as "patch madness"
Looking at more recent things. For SLE 12 the base version of the
kernel is 3.12. However, this kernel has many features from kernels
that were released later plus bug fixes etc. Currently the patch count
for this kernel is around 5500. There will be no version upgrade for
the kernel for SP1, thus the number of patches will continue to grow.
For the kernel patches are organized in categories and things are
tracked in a specific file (series.conf).
For other packages things work in similar ways, i.e. the base version
stays the same and then patches are applied. However as the upstream
development does not progress as fast as the kernel, patch counts for
glibc and other core components of a Linux system are much lower. For
glibc the patch count is around 60 at the moment, for example.
Anyway to make a long story short, the key points are probably:
- - Base versions in SLE rarely change (compared to openSUSE)
- - New features and bug fixes are provided via patches rather than
- - More patches implies additional effort to track stuff
And just for comparison the current version of glibc in 13.2 carries
about the same amount of patches than the version in SLES 12. The
kernel in 13.2 has an order of magnitude fewer patches (537) than the
Robert Schweikert MAY THE SOURCE BE WITH YOU
Public Cloud Architect LINUX
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org