![](https://seccdn.libravatar.org/avatar/b305db35a59e18dee3599a13faf265a0.jpg?s=120&d=mm&r=g)
On Sun, 2009-08-30 at 12:47 +0200, Jan Engelhardt wrote:
On Sunday 2009-08-30 08:28, Sven-Thorsten Dietrich wrote:
During the support cycle, its nice to have the security and critical fix stream generated by the Suse Kernel folks, as well as some of the driver freshening.
I am not quite sure what you try to showcase. It is possibly true that SUSE can patch their kernel rpm faster than waiting for the next -stable update to contain a security fix, but on the other hand I have also seen SUSE not providing all -stable updates either, sometimes letting time seemingly pass, and skipping things like 2.6.25.11 -> 2.6.25.16.
Stable expires usually within 2 revs of the Kernel, well before the Kernel support for OpenSUSE, so therein lies the value add of the Suse Kernel. In regards to the issue of stable updates, often individual patches that make up a stable release are put into the Kernel tree before the stable release hits upstream. Dropping them back out and replacing with stable is then not time critical, since the broken out components are in the tree. This may go on for several releases, which may be in-part causing the skipped stable releases. Whether things are complete or lagging at any given point or for a specific Kernel is a matter of forensics. Whatever isn't covered by the above - its true that we all would like to have more time, more engineers, and more QA to get things out faster, but we all are doing what we can with what we've got. And we do appreciate the input. Hopefully the git tree will help make things easier whenever that is made available.
series.conf is not the main problem, the rest is.
Because now everybody wanting to add patches or modifying other parts, such as the .spec(.in) files or anything else has to do that to two packages. It's like we are back to providing only .spec files and no master .spec.in.
Last time I checked, RT and HEAD were using almost identical spec files. The diffs were in declaring the RT variant and other odd bits.
What I am saying is that if modifications to kernel/some.spec is made, you also have to make the changes to kernel-rt/some.spec. In its simplest case it is a /bin/cp operation, but it may not. Either way, it is extra work.
We will work towards that in the future.
I think it would be more logical to ship multiple series.conf in one src.rpm. series.conf *into one* src.rpm.
This would help with the KMP problem as well...
I do not see how this would relate. Whether one .src.rpm produces {kernel, kernel-source, kernel-rt, kernel-rt-source} packages, or two .src.rpms produce {kernel, kernel-source} {kernel-rt, kernel-rt-source} does not make much of a difference to the user.
If you however mean kernel-source (yes, it is now known under a new name..) containing both kernel-source and kernel-rt-source — hey, cool idea — you may want to use fdupes. Does not rpm already do fdupes automatically?
I am honestly not familiar enough with all the intricacies / dependencies / requirements of the build system, so I can't answer that in a useful manner. We spent quite some time talking about the RT issue, and maintaining separately seemed to be the best option at least for the near- to mid- term.
Eventually (once development moves past 2.6.31), I will use the +RT guard with RT at the end of the Suse patch queue.
I will resolve the conflicts and adding small fixups individually per interdiff or from upstream git.
That would mean a state where the tree would not compile and/or run properly, hurting bisectability (and yes, I do have to do that sometimes with the entire patch queue).
The old broken-out RT patch set is now several git branches. I haven't scoped how straightforward it would be to break things out.
I meant bisecting the SUSE patch gubble and whatever else I added (after all, they make up the majority of series.conf), not upstream patches.
I think upstream is best left as megapatches, and I find it simpler to just provide patches.kernel/2.6.31-rc7 [56729KB] instead of patches.kernel/2.6.31-rc1 + patch-2.6.31-rc1-rc2 + ... -rc6-rc7 [totalling 59505KB], simply for size. They should be reasonably correct.
Here I am just following with RT what other people are doing, so that is not up to me, but its the right list :)
Of course: The ideal situation would be to apply the RT patch unconditionally, and then work with config/flavors to enable the various features.
I am doing that already, but thanks for trying ;-)
Thanks for the feedback - lets maybe discuss more FTF in Dresden?
What is in Dresden?
I will be there for the RT Linux Foundation Meeting end of September. Sven -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org