1:37 p.m.
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.
3:11 p.m.
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 at ATrpms.net
12:47 a.m.
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
2:12 a.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.
If it builds for xen0 it builds for xen.
--
Axel.Thimm at ATrpms.net
4:21 a.m.
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*?
6:14 a.m.
New subject: OT: xen vs xen0 (was: kernel-module packaging discussing broken into pieces: One specfile approach vs. splitted spec file)
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
--
Axel.Thimm at ATrpms.net
6:38 a.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.
--
Axel.Thimm at ATrpms.net
6:36 a.m.
New subject: kmdls: very good support for custom kernels (was: kernel-module packaging discussing ...)
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.
--
Axel.Thimm at ATrpms.net
5:11 a.m.
New subject: kmdls: very good support for custom kernels (was: kernel-module packaging discussing ...)
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.
5:34 a.m.
New subject: kmdls: very good support for custom kernels (was: kernel-module packaging discussing ...)
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 at ATrpms.net
5:54 a.m.
New subject: kmdls: very good support for custom kernels (was: kernel-module packaging discussing ...)
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
6:11 a.m.
New subject: kmdls: very good support for custom kernels (was: kernel-module packaging discussing ...)
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 at ATrpms.net
6:30 a.m.
New subject: kmdls: very good support for custom kernels (was: kernel-module packaging discussing ...)
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
7:55 a.m.
New subject: kmdls: very good support for custom kernels (was: kernel-module packaging discussing ...)
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 at ATrpms.net
8:02 a.m.
New subject: kmdls: very good support for custom kernels (was: kernel-module packaging discussing ...)
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
3:16 p.m.
New subject: kmdls: very good support for custom kernels (was: kernel-module packaging discussing ...)
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 at ATrpms.net
6:39 a.m.
New subject: kmdls: very good support for custom kernels (was: kernel-module packaging discussing ...)
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
8:55 a.m.
New subject: kmdls: very good support for custom kernels (was: kernel-module packaging discussing ...)
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.
--
Axel.Thimm at ATrpms.net
6:03 a.m.
New subject: kmdls: very good support for custom kernels (was: kernel-module packaging discussing ...)
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.
6:14 a.m.
New subject: kmdls: very good support for custom kernels (was: kernel-module packaging discussing ...)
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.
--
Axel.Thimm at ATrpms.net
6453
days inactive
6456
days old
packaging@lists.fedoraproject.org
19 comments
3 participants
participants (3)
-
Axel Thimm -
Thorsten Leemhuis -
Ville Skyttä