kernel-module packaging discussing broken into pieces: One specfile approach vs. splitted spec file
Hi all!
There are ways to many things to discuss with the current proposed schemes for packaging kernel-modules. That's why I'd like to break it up into pieces and give some details of the different implementation details. I choose to start with the "One specfile approach vs. splitted spec files" discussion because that's a bit easier to discuss then the "uname -r" stuff where even I'm still unsure how to proceed.
Axel, could you please take a look at this? Did I miss anything (I surely did)? I tried to concentrate on the technical details.
== One specfile approach vs. splitted spec file ==
Mainly a matter of taste. Some prefer the one specfile approach that's used by kmdls, other the slitted approach used by kmods. The differences:
* debuginfo packages for kmdls won't get created with the automatic stuff that rpm normally uses; a script/macro that is mainly an enhanced copy of the stuff that's used by rpm currently handles that (see https://www.redhat.com/archives/fedora-packaging/2006-August/msg00053.html); that could be easily integrated into the standard macros shipped by FC / RHEL * the one-specfile approach needs some sort of mechanism to make sure that * the userland part normally isn't build for i586 and i686 because that's normally unneeded * the kernel-modules can't be build for i386 because there is no i386 kernel in FC) This is realized by %if %else %endif constructs in the spec file with the "kmdl_userland" define (see http://fedoraproject.org/wiki/AxelThimm/kmdls for details), that needs to be set by the buildsys when rpmbuild is called to build stuff * the buildsys must queue the rebuild of a kmdl srpm multiple times to get modules for all kernel flavours build in the kmdl case -- the kmods scheme can build all in one step. The variants and the kernel-version are currently hardcoded in the kmod standard because the Extras buildsys doesn't support passing the variants and the kernel version to rpmbuild call yet. Axel says that the kmod scheme is not "kernel {version,flavor} agnostic" due to this hardcoding. But this hardcoding currently allow us to build the kmods without other changes in the buildsys; kmdls can't get build without special support in the buildsys due to the needed "rebuild one srpm multiple times" * the kmod standard has the disadvantage that there are multiple srpms (e.g. one for kernel 2157 and one for kernel 2174). But this way we make sure that the
Note: There is a really big area where parts/ideas of one approach could be moved over to the other and the other way around. E.g. kmods could get rid of the "kversion" in "%{RELEASE}" of the SRPMS and create the debuginfo packages manually just like kmdls do -- that would solve the "multiple SRPMS" problem. kmdls also could hardcode the kversion and kflavor stuff and use loops just like kmods -- then they would be buildable with the current buildsys.
On Wed, Aug 16, 2006 at 08:37:42PM +0200, Thorsten Leemhuis wrote:
Axel, could you please take a look at this? Did I miss anything (I surely did)? I tried to concentrate on the technical details.
BTW this has nothing to do with the one-specfile approach but nonetheless:
- the buildsys must queue the rebuild of a kmdl srpm multiple times to
get modules for all kernel flavours build in the kmdl case -- the kmods scheme can build all in one step. The variants and the kernel-version are currently hardcoded in the kmod standard because the Extras buildsys doesn't support passing the variants and the kernel version to rpmbuild call yet. Axel says that the kmod scheme is not "kernel {version,flavor} agnostic" due to this hardcoding. But this hardcoding currently allow us to build the kmods without other changes in the buildsys; kmdls can't get build without special support in the buildsys due to the needed "rebuild one srpm multiple times"
Bundeling many flavours in one build is bad, hardcoded or not. Having 4 dozens of kmdls around my belt I know that some kmdls don't build at all on some flavours, the xen family currently displaying this quite nicely, about 30-40% of kmdls are not buildable on them. When a flavour fails to build it is either so by design, so nothing can be done, or the kmdl can be fixed on package-level or upstream, or the kernel can be fixed. Therefore you don't want the specfile to dictate which flavours to build for, you want it to get this information from the buildsystem (or not at all, the information about the flavour is not even needed in kmdl schemes ...)
Also flavours may come and go within a distribution's life cycle. For example a few weeks ago "xen" was added to FC5 along "xen0". No need to touch specfile/src.rpm/userland in the kmdl scheme to add supportfor the newcomer. For example the sole representant of kmods in FE is em8300. Where is his "xen" flavour?
And don't forget custom kernel packages and support for them. I forgot to mention this: ATrpms has contributed swsups2 kernels for FC4 and FC5. By having the specfile/src.rpm kernel and flavour agnostic *and* unbundled I can use the same specfile/src.rpm/userland for these extras kernels/flavours, too. CCRMA has a set of their own kernels, too.
So true kernel/flavour agnosticism and non-bundling of builds is a true blessing.
Now about the buildsystem: My home-brewn buildsys has about 20 lines of code to support multiple builds of the kmdl src.rpm, I don't expect extending FC's and FE's buildsystem to be rocket science (BTW I did study physics, so I'm good at rocket science ;) and I offered to put my man hours into this (unless it get's all burned up before ...)
It's better to extend the buildsystem than to have hardcoded kernels & flavours in all kmdl specfiles/src.rpm, have to unneccessarily rebuild src.rpm, be forced to split subpackages into twin src.rpms and the like. These are all unneccessary hacks, let's attack the real problem, extending the buildsystem.
- the kmod standard has the disadvantage that there are multiple srpms
(e.g. one for kernel 2157 and one for kernel 2174). But this way we make sure that the
This mail looks unfinished.
Axel Thimm schrieb:
On Wed, Aug 16, 2006 at 08:37:42PM +0200, Thorsten Leemhuis wrote:
Axel, could you please take a look at this? Did I miss anything (I surely did)? I tried to concentrate on the technical details.
BTW this has nothing to do with the one-specfile approach
As I said in my mail:
Note: There is a really big area where parts/ideas of one approach could be moved over to the other and the other way around. [...]
but nonetheless:
- the buildsys must queue the rebuild of a kmdl srpm multiple times to
get modules for all kernel flavours build in the kmdl case -- the kmods scheme can build all in one step. The variants and the kernel-version are currently hardcoded in the kmod standard because the Extras buildsys doesn't support passing the variants and the kernel version to rpmbuild call yet. Axel says that the kmod scheme is not "kernel {version,flavor} agnostic" due to this hardcoding. But this hardcoding currently allow us to build the kmods without other changes in the buildsys; kmdls can't get build without special support in the buildsys due to the needed "rebuild one srpm multiple times"
Bundeling many flavours in one build is bad, hardcoded or not.
I disagree.
Having 4 dozens of kmdls around my belt I know that some kmdls don't build at all on some flavours, the xen family currently displaying this quite nicely, about 30-40% of kmdls are not buildable on them. When a flavour fails to build it is either so by design, so nothing can be done, or the kmdl can be fixed on package-level or upstream, or the kernel can be fixed. Therefore you don't want the specfile to dictate which flavours to build for, you want it to get this information from the buildsystem (or not at all, the information about the flavour is not even needed in kmdl schemes ...)
Sure, but that *can* be filtered within kmod spec file if we want to. It it could also be done by the buildsys (that's what I'd prefer). In your case the buildsys would have to do it. So none of the two is really better then the other. Just a matter of taste.
Also flavours may come and go within a distribution's life cycle. For example a few weeks ago "xen" was added to FC5 along "xen0". No need to touch specfile/src.rpm/userland in the kmdl scheme to add supportfor the newcomer. For example the sole representant of kmods in FE is em8300. Where is his "xen" flavour?
You'd have to ask scop. Maybe it didn't build, don't know. But just as above: there is no difference between kmdls and kmods when the buildsys handles that. In the kmod case the buildsys can simply run
rpmbuild kmod-foo.src.rpm --define 'kversion 2.6.17-1.2145_FC5' --define 'kvariants "" smp xen xen0 XenU bigsmp never_have_heard_of_flavor'
and it's build as long as never_have_heard_of_flavor exists -- no modifications to the specfile needed.
And don't forget custom kernel packages and support for them. I forgot to mention this: ATrpms has contributed swsups2 kernels for FC4 and FC5. By having the specfile/src.rpm kernel and flavour agnostic *and* unbundled I can use the same specfile/src.rpm/userland for these extras kernels/flavours, too. CCRMA has a set of their own kernels, too.
This works for kmod, too, as long as the custom kernel follows the FC kernel scheme exactly.
So true kernel/flavour agnosticism and non-bundling of builds is a true blessing.
As I said: There is no real difference between kmods and kmdls here if the buildsys handles everything.
[...]
- the kmod standard has the disadvantage that there are multiple srpms
(e.g. one for kernel 2157 and one for kernel 2174). But this way we make sure that the
This mail looks unfinished.
Yeap. It should end with:
But this way we make sure that the SRPMS listed by "rpm -qi" really is the source rpm that was used to build stuff. Some people wanted that, but that's no big deal.
CU thl
On Thu, Aug 17, 2006 at 07:47:41AM +0200, Thorsten Leemhuis wrote:
Also flavours may come and go within a distribution's life cycle. For example a few weeks ago "xen" was added to FC5 along "xen0". No need to touch specfile/src.rpm/userland in the kmdl scheme to add supportfor the newcomer. For example the sole representant of kmods in FE is em8300. Where is his "xen" flavour?
You'd have to ask scop. Maybe it didn't build, don't know.
If it builds for xen0 it builds for xen.
On Thu, 2006-08-17 at 09:12 +0200, Axel Thimm wrote:
On Thu, Aug 17, 2006 at 07:47:41AM +0200, Thorsten Leemhuis wrote:
FE is em8300. Where is his "xen" flavour?
You'd have to ask scop. Maybe it didn't build, don't know.
If it builds for xen0 it builds for xen.
I'm not aware of any problems building it, but nor am I knowledgeable enough about Xen to be able to tell whether shipping this particular module package for the FC5 "xen" variant makes sense in the first place even if it compiles fine. So I just followed what GFS and friends do and didn't build for "xen". Maybe that's a bug?
Some info about the different xen variants from the POV of for which of them in general it makes sense to ship hardware device drivers such as this one would be nice. WAG: xen0 and xen yes, xenU no? And if the module is not a hardware device driver but something else, then in general ship+build for all xen*?
On Thu, Aug 17, 2006 at 12:21:49PM +0300, Ville Skyttä wrote:
On Thu, 2006-08-17 at 09:12 +0200, Axel Thimm wrote:
On Thu, Aug 17, 2006 at 07:47:41AM +0200, Thorsten Leemhuis wrote:
FE is em8300. Where is his "xen" flavour?
You'd have to ask scop. Maybe it didn't build, don't know.
If it builds for xen0 it builds for xen.
I'm not aware of any problems building it, but nor am I knowledgeable enough about Xen to be able to tell whether shipping this particular module package for the FC5 "xen" variant makes sense in the first place even if it compiles fine. So I just followed what GFS and friends do and didn't build for "xen". Maybe that's a bug?
If GFS didn't build for xen, but for xen0, it's a bug in GFS or the associated buildsystem. Maybe exactly the design issues I'm referring to of hardwiring the flavours in the specfile/src.rpm, or maybe something else, in any case a bug. :)
Some info about the different xen variants from the POV of for which of them in general it makes sense to ship hardware device drivers such as this one would be nice. WAG: xen0 and xen yes, xenU no? And if the module is not a hardware device driver but something else, then in general ship+build for all xen*?
Rules of thumb: o Everything *should* build under xen and xen0, they are both domain0 kernels (but see below) o Not everything even makes sense under xenU (e.g. nvidia-graphics), this is the guest kernel.
If something does not work with xen or xen0 it's either a bug in these flavours (forgetting to export something, or exporting an updated symbol/signature of say 2.6.18 on 2.6.17, this has bitten me quite some times like the premature _xmit_lock* changes) or a bug in the upstream kernel module project.
But wrt xen vs xen0: iff it builds on one of them then it builds on the other. That's 99.9% sure. Just for reference, here are the differences between those two:
-CONFIG_HIGHMEM4G=y -# CONFIG_HIGHMEM64G is not set +# CONFIG_HIGHMEM4G is not set +CONFIG_HIGHMEM64G=y @@ -3078,2 +3079,2 @@ -CONFIG_XEN_BLKDEV_BACKEND=y -CONFIG_XEN_NETDEV_BACKEND=y +CONFIG_XEN_BLKDEV_BACKEND=m +CONFIG_XEN_NETDEV_BACKEND=m @@ -3103,0 +3105,8 @@ +# CONFIG_NOHIGHMEM is not set +# CONFIG_HIGHMEM4G is not set +CONFIG_HIGHMEM64G=y +CONFIG_HIGHMEM=y +CONFIG_XEN_BLKDEV_BACKEND=m +CONFIG_XEN_NETDEV_BACKEND=m +CONFIG_XEN_BLKDEV_FRONTEND=m +CONFIG_XEN_NETDEV_FRONTEND=m
On Thu, Aug 17, 2006 at 07:47:41AM +0200, Thorsten Leemhuis wrote:
Also flavours may come and go within a distribution's life cycle. For example a few weeks ago "xen" was added to FC5 along "xen0". No need to touch specfile/src.rpm/userland in the kmdl scheme to add supportfor the newcomer. For example the sole representant of kmods in FE is em8300. Where is his "xen" flavour?
You'd have to ask scop. Maybe it didn't build, don't know. But just as above: there is no difference between kmdls and kmods when the buildsys handles that. In the kmod case the buildsys can simply run
rpmbuild kmod-foo.src.rpm --define 'kversion 2.6.17-1.2145_FC5' --define 'kvariants "" smp xen xen0 XenU bigsmp never_have_heard_of_flavor'
and it's build as long as never_have_heard_of_flavor exists -- no modifications to the specfile needed.
And adding to my reply: It first looks as if the kmod scheme could now build some flavours apart form others. But due to the bundling of building all flavours together and sharing *one* debuginfo package for all kmods this is impossible, or possible, but would nuke the "old" debuginfo package from the previous build. kmdls have one debuginfo per kmdl, therefore you can build flavour/kernels/custon kernels/custom flavours at your own pace w/o the need to rebuild all each time.
On Wed, Aug 16, 2006 at 10:11:44PM +0200, Axel Thimm wrote:
And don't forget custom kernel packages and support for them. I forgot to mention this: ATrpms has contributed swsups2 kernels for FC4 and FC5. By having the specfile/src.rpm kernel and flavour agnostic *and* unbundled I can use the same specfile/src.rpm/userland for these extras kernels/flavours, too. CCRMA has a set of their own kernels, too.
I have added this argument to the wiki. kmdls allow you to bolster your oen kernel package called my-special-kernel-2.6.18-111 and support it with kmdls.
Background: custom kernel packages should always either change the main name of the rpm package or introduce themselves as a new flavour otherwise they get rpm-sorted into the same upgrade path like vendor kernels which neither the vendor, nor the author of the custom kernel package wants to happen.
kmdls fully support custom kernel rpms.
On Thu, 2006-08-17 at 13:36 +0200, Axel Thimm wrote:
I have added this argument to the wiki. kmdls allow you to bolster your oen kernel package called my-special-kernel-2.6.18-111 and support it with kmdls.
[...]
kmdls fully support custom kernel rpms.
This is one new example about the inaccuracies/omissions of the current Wiki docs and belongs in the area I don't think makes sense to even discuss at the moment, but because "FUD" appeared in one of the responses to my previous message, I'll bite:
And kmods don't because they require specific Provides from the target kernel? Requires: /boot/vmlinuz-* is a no go, it's non-portable (example: ia64) and not arch-qualified (example: possible i586/i686 modules/kernel mismatch).
If the argument is that implementation of the kmdl macros can be changed according to what's available in the target system, so can kmodtool and the related macros.
On Fri, Aug 18, 2006 at 01:11:57PM +0300, Ville Skyttä wrote:
On Thu, 2006-08-17 at 13:36 +0200, Axel Thimm wrote:
I have added this argument to the wiki. kmdls allow you to bolster your oen kernel package called my-special-kernel-2.6.18-111 and support it with kmdls.
[...]
kmdls fully support custom kernel rpms.
This is one new example about the inaccuracies/omissions of the current Wiki docs and belongs in the area I don't think makes sense to even discuss at the moment, but because "FUD" appeared in one of the responses to my previous message, I'll bite:
FUD appeared due to making vague statements against something w/o backing them up. You yourself described that as "sucks".
And kmods don't because they require specific Provides from the target kernel? Requires: /boot/vmlinuz-* is a no go, it's non-portable (example: ia64) and not arch-qualified (example: possible i586/i686 modules/kernel mismatch).
arch is no issue, it's the same mechanism as for the kernel itself (so if it is an issue you have much bigger problems to worry about - still even then the kmdls would arch-match with the kernel), and ia64 has yet to become an official FC distribution. Currently it is banned onto the shoulders of IBM. BTW I've been asked to rebuild ATrpms for ia64 and maybe they'll even ship ia64 hardware to me.
The current choice covers all sensible archs and all sensible distributions including RHEL3 and even RHL7.3-RH9 (probably even earlier). It also covers Mandriva, SuSE and most other rpm distributions. Yes, who cares about RH9, but a lot still care about RHEL and allowing access to other distributions increases the cross-distribution acceptance and make chances for a common standard even better.
And to cut to the chase: Ever tried to support special kernel rpms like swsusp2 or ccrma's low-latency kernels? I did and know it works for kmdl and will fail with kmod.
If the argument is that implementation of the kmdl macros can be changed according to what's available in the target system, so can kmodtool and the related macros.
W/o a src.rpm/userland rebuild including evr bumps and w/o having to split src.rpms per distro? That's a very big difference. You can use kmdl src.rpm today on RHEL3 or SuSE w/o a change. And on any arbitray custom kernel package, which was what this point is about.
Axel Thimm schrieb:
On Fri, Aug 18, 2006 at 01:11:57PM +0300, Ville Skyttä wrote:
On Thu, 2006-08-17 at 13:36 +0200, Axel Thimm wrote:
[ignoring the FUD debatte]
[ignoring the arch debatte]
And to cut to the chase: Ever tried to support special kernel rpms like swsusp2 or ccrma's low-latency kernels? I did and know it works for kmdl and will fail with kmod.
I looked into this once and I'd like to give people a bit more background from my point of view:
Yes, kmod fails for the swsusp2 kernel from http://mhensler.de/swsusp/. But that's not directly a bug/problem in kmod. kmods would work if the swsusp2 kernel would be packaged exactly in the same way as the FC kernels are packaged. But that's not the case.
CU thl
On Fri, Aug 18, 2006 at 12:54:06PM +0200, Thorsten Leemhuis wrote:
Axel Thimm schrieb:
On Fri, Aug 18, 2006 at 01:11:57PM +0300, Ville Skyttä wrote:
On Thu, 2006-08-17 at 13:36 +0200, Axel Thimm wrote:
[ignoring the FUD debatte]
[ignoring the arch debatte]
And to cut to the chase: Ever tried to support special kernel rpms like swsusp2 or ccrma's low-latency kernels? I did and know it works for kmdl and will fail with kmod.
I looked into this once and I'd like to give people a bit more background from my point of view:
Yes, kmod fails for the swsusp2 kernel from http://mhensler.de/swsusp/. But that's not directly a bug/problem in kmod. kmods would work if the swsusp2 kernel would be packaged exactly in the same way as the FC kernels are packaged. But that's not the case.
which was done deliberately to not conflict with having the same name with a Fedora package, just as the highest mandate coming from Fedora to 3rd parties is, right?
Just FYI FC4 packages do still have the same name with FC, "kernel", which means that once you start using a swsups2 kernel your normal vendor kernels don't get updated because swsups2 is evr-newer. And CCRMA's kernel had been following the "kernel" naming, but have lower evr that the vendor's, which mean that yum doesn't ever upgrade the CCRMA kernel. CCRMA therefore had to replace FC's yum with a pathced version. So both cases in 'packaged exactly in the same way as the FC kernels' are rather disastrous and in automatic conflict with other FC credos like no replacing of core packages like kernel/yum.
Pick your choice in kmod land:
o lock in onto custom kernels due to exact naming with the vendor's o no updates to your custom kernel due to exact naming with the vendor's o no support for custom kernels due to different naming with the vendor's
...
Axel Thimm schrieb:
On Fri, Aug 18, 2006 at 12:54:06PM +0200, Thorsten Leemhuis wrote:
Axel Thimm schrieb:
On Fri, Aug 18, 2006 at 01:11:57PM +0300, Ville Skyttä wrote:
On Thu, 2006-08-17 at 13:36 +0200, Axel Thimm wrote:
And to cut to the chase: Ever tried to support special kernel rpms like swsusp2 or ccrma's low-latency kernels? I did and know it works for kmdl and will fail with kmod.
I looked into this once and I'd like to give people a bit more background from my point of view:
Yes, kmod fails for the swsusp2 kernel from http://mhensler.de/swsusp/. But that's not directly a bug/problem in kmod. kmods would work if the swsusp2 kernel would be packaged exactly in the same way as the FC kernels are packaged. But that's not the case.
which was done deliberately to not conflict with having the same name with a Fedora package, just as the highest mandate coming from Fedora to 3rd parties is, right?
Right, but it can be done in different ways, e.g. in a ways, that follows the general naming and file-placing behavior from the Fedora kernels or in ways that differ -- in case of the swsusp the latter was chosen.
CU thl
On Fri, Aug 18, 2006 at 01:30:06PM +0200, Thorsten Leemhuis wrote:
Axel Thimm schrieb:
On Fri, Aug 18, 2006 at 12:54:06PM +0200, Thorsten Leemhuis wrote:
Axel Thimm schrieb:
On Fri, Aug 18, 2006 at 01:11:57PM +0300, Ville Skyttä wrote:
On Thu, 2006-08-17 at 13:36 +0200, Axel Thimm wrote:
And to cut to the chase: Ever tried to support special kernel rpms like swsusp2 or ccrma's low-latency kernels? I did and know it works for kmdl and will fail with kmod.
I looked into this once and I'd like to give people a bit more background from my point of view:
Yes, kmod fails for the swsusp2 kernel from http://mhensler.de/swsusp/. But that's not directly a bug/problem in kmod. kmods would work if the swsusp2 kernel would be packaged exactly in the same way as the FC kernels are packaged. But that's not the case.
which was done deliberately to not conflict with having the same name with a Fedora package, just as the highest mandate coming from Fedora to 3rd parties is, right?
Right, but it can be done in different ways, e.g. in a ways, that follows the general naming and file-placing behavior from the Fedora kernels or in ways that differ -- in case of the swsusp the latter was chosen.
Just outline a way that custom kernel packages could be created Fedora-conform and be supported by kmods, because I just stated in the mail you replied to, that this is impossible:
If you follow Fedora compliance you lose kmod support, if you follow kmod compliance you lose Fedora compliance.
I also showed real life examples for all cases.
Axel Thimm schrieb:
On Fri, Aug 18, 2006 at 01:30:06PM +0200, Thorsten Leemhuis wrote:
Axel Thimm schrieb:
On Fri, Aug 18, 2006 at 12:54:06PM +0200, Thorsten Leemhuis wrote:
Axel Thimm schrieb:
On Fri, Aug 18, 2006 at 01:11:57PM +0300, Ville Skyttä wrote:
On Thu, 2006-08-17 at 13:36 +0200, Axel Thimm wrote:
And to cut to the chase: Ever tried to support special kernel rpms like swsusp2 or ccrma's low-latency kernels? I did and know it works for kmdl and will fail with kmod.
I looked into this once and I'd like to give people a bit more background from my point of view:
Yes, kmod fails for the swsusp2 kernel from http://mhensler.de/swsusp/. But that's not directly a bug/problem in kmod. kmods would work if the swsusp2 kernel would be packaged exactly in the same way as the FC kernels are packaged. But that's not the case.
which was done deliberately to not conflict with having the same name with a Fedora package, just as the highest mandate coming from Fedora to 3rd parties is, right?
Right, but it can be done in different ways, e.g. in a ways, that follows the general naming and file-placing behavior from the Fedora kernels or in ways that differ -- in case of the swsusp the latter was chosen.
Just outline a way that custom kernel packages could be created Fedora-conform and be supported by kmods,
Just use the same scheme that a new flavor in the main package would use.
CU thl
On Fri, Aug 18, 2006 at 03:02:52PM +0200, Thorsten Leemhuis wrote:
Just use the same scheme that a new flavor in the main package would use.
That would be for new flavours, not new kernels that share the same set of flavours like the unpatched kernel.
Axel Thimm schrieb:
On Fri, Aug 18, 2006 at 03:02:52PM +0200, Thorsten Leemhuis wrote:
Just use the same scheme that a new flavor in the main package would use.
That would be for new flavours, not new kernels that share the same set of flavours like the unpatched kernel.
Sorry, I fail to follow you. Why can the flavor be something like "swsusp2", "swsusp2-smp", "swsusp2-xen", ...?
CU thl
On Sat, Aug 19, 2006 at 01:39:25PM +0200, Thorsten Leemhuis wrote:
Axel Thimm schrieb:
On Fri, Aug 18, 2006 at 03:02:52PM +0200, Thorsten Leemhuis wrote:
Just use the same scheme that a new flavor in the main package would use.
That would be for new flavours, not new kernels that share the same set of flavours like the unpatched kernel.
Sorry, I fail to follow you. Why can the flavor be something like "swsusp2", "swsusp2-smp", "swsusp2-xen", ...?
Why should it? The flavour is simply the choice of a config file (not 100% true, but let's keep it simple), that's why it is called a flavour after all. Overloading it with further information is wrong, especially when the sole purpose is only to support the kmod hack.
Any custom kernel package out there is either not changing the name or is suffixing the main name with suspend2/desktop etc. Noone wants to start hacking new flavours.
On Fri, 2006-08-18 at 12:34 +0200, Axel Thimm wrote:
arch is no issue [...] and ia64 has yet to become an official FC distribution. [...] The current choice covers all sensible archs and all sensible distributions [...]
'nuff said, thanks.
On Fri, Aug 18, 2006 at 02:03:38PM +0300, Ville Skyttä wrote:
On Fri, 2006-08-18 at 12:34 +0200, Axel Thimm wrote:
arch is no issue [...] and ia64 has yet to become an official FC distribution. [...] The current choice covers all sensible archs and all sensible distributions [...]
'nuff said, thanks.
Removing quoting is a serious form of misquoting. I gave explanations to the above in what you removed. As you quote them the statement sounds far different that in the proper context.
packaging@lists.fedoraproject.org
-
Axel Thimm -
Thorsten Leemhuis -
Ville Skyttä