On Fri, 10 Jun 2016 23:06:17 +0200, Greg Freemyer wrote:
On Fri, Jun 10, 2016 at 1:50 PM, Stefan Seyfried
wrote: 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.
Best regards,
Stefan -- Stefan Seyfried
Got it.
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 install?
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 resources, yes. 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 LTS kernel. * 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 stable tree. Hopefully this will get you a more concrete idea how to maintain your kernel project. thanks, Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org