On Fri, 10 Jun 2016 23:06:17 +0200,
Greg Freemyer wrote:
On Fri, Jun 10, 2016 at 1:50 PM, Stefan Seyfried
Am 10.06.2016 um 16:46 schrieb Greg Freemyer:
I've got the Leap 42.2 Kernel in a
Kernel:LTS tracking project. It
should get all the SLE 12 SP2 kernel patches/updates automatically.
I'm building for Tumbleweed, Leap 42.1, 13,2, and 13.1.
There is no need for building the kernel multiple times for different
distributions. Just building against Factory or Tumbleweed will do.
See Kernel:HEAD, Kernel:stable or Kernel:vanilla for setup hints.
With you setup you are wasting lots of buildservice power.
Given your statement, Is it appropriate to say the main benefit of a
standalone Kernel:LTS repo is that users don't have to worry about
pulling in non-kernel related packages like they would if they were to
add the full Leap:42.2 repo?
Also, in can be built against by any kernel modules maintainers that
would like to test their modules without requiring a full Leap 42.2
Or am I just wasting my cycles trying to promote this?
The kernel package that is built even with a newer gcc can be deployed
to older distros in general. Also, building a KMP with an older gcc
for a kernel with a newer gcc usually works. In that sense, building
the same kernel package for multiple distro versions is a waste of
One possible problem for deploying a new kernel to an old distro would
be the difference of mkinitrd stuff or module-init-tools. But it
should be no problem if the distro is 13.1 or later.
That being said, there is no much merit to rebuilding the whole
again, as long as the code is same as 42.2 kernel.
Of course, if you're willing to maintain the next LTS kernel (4.10 or
whatever), it's a different question. In general, tracking the
upstream stable kernel is really easy. It's a monkey work.
However, there are a few more difficult tasks:
* kABI compatibility
For keeping KMPs working, you'd need to keep the kABI compatible. And
this is the most difficult task while maintaining the kernel package.
If you don't keep kABI compatibility, it means a rolling release like
TW, i.e. all KMPs have to be rebuilt against the new kernel at each
time. If we define such a policy, it's fine. But then you'll have a
project linking every KMP into the same kernel project.
* kconfig adjustment
The kernel config has to be updated properly after the kernel
upgrade. Though, this can be done by following TW kernel
development. But you'll need to check the compatibility from the
previous LTS Kernel as wel.
* Bug report handling
As a maintainer, you'll need to deal with each bug report against your
* Taking and maintaining own patches
Taking own fix patches that aren't in stable tree depend on the
maintainer. Leap 42.1 kernel have a significant number of own
patches, for example.
* Security fixes
Sometimes you'll need to handle security fixes before handled in
Hopefully this will get you a more concrete idea how to maintain your
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org