Hi all,
there is currently a discussion about replacing the current kernel module scheme ("kmod") with a new one ("kmdls"). This is because the current scheme has some unfixable flaws. The proposed new scheme is the one used at ATrpms, so if you ever used a kernel module package from there you know how it is setup.
The kmdl approach has several nice features other than being resistant to the design issues of the current setup.
* It is an interface/implementation design that can actually even be used for the current (broken) setup. The specfile remains invariant.
* It uses one specfile/src.rpm for both userland and kernel modules, e.g. one set of sources/patches/changelogs/bugzilla entries/owners.
* It is kernel and kernel-flavour agnostic, the same specfile/src.rpm can be used for any kernel/flavour combination, even for such that are yet to come.
* Has full yum-support with a 99-line python plugin, works even w/o the plugin with a couple more keystrokes.
* Is field-proven for several years and managed to never have to change the interface!
More details are on http://fedoraproject.org/wiki/AxelThimm/kmdls
It is important for FC6 and RHEL5 to make a decision on adopting it. Currently GFS is being packaged in the old scheme which is known to exhibit several flaws.
An argument against adopting kmdls presented by Thorsten Leemhuis is that
* it's too late now to fix it, we should live on with kmod bugs for RHEL5's life-cycle (ending 2012 ...)
* too many packages for kmod are written (but actually there is only one in Fedora Extras 5, the rest is pending or in other repos and if other repos count, then ATrpms has several dozens of kmdls :)
I think the flaws are severe enough to immediate block the current kmod standard especially it's propagation into RHEL. The wiki above shows that the design flaws propagate throughout any attemt to "fix" yum (note: yum is not broken, there the quotes in "fix") and finally end with the requirement that only one kernel can be supported in any point of time. This is neither acceptable by Fedora, and even less be RHEL.
The number of packages following the kmod standard are quite few and I hope that the authors will not mind using the kmdl standard, but that's for you to say.
Especially if you are a kernel module package author or want to become one: Please check the wiki and if you care about it join the discussion at fedora-packaging - reply-to set to that list, please don't scatter the discussion on fedora-extras and fedora-devel, I'm only calling for participation in the discussion to get this nailed once and for all. Thanks!
On Tue, Aug 15, 2006 at 02:34:06PM +0200, Axel Thimm wrote:
Especially if you are a kernel module package author or want to become one: Please check the wiki and if you care about it join the discussion at fedora-packaging - reply-to set to that list, please don't scatter the discussion on fedora-extras and fedora-devel, I'm only calling for participation in the discussion to get this nailed once and for all. Thanks!
I messed up with fedora-packaging's mail address, it's fedora-packaging@redhat.com, not fedora-packaging-list@redhat.com
So please fix it before replying :)
On Tue, 2006-08-15 at 14:34 +0200, Axel Thimm wrote:
An argument against adopting kmdls presented by Thorsten Leemhuis is that
it's too late now to fix it, we should live on with kmod bugs for RHEL5's life-cycle (ending 2012 ...)
too many packages for kmod are written (but actually there is only one in Fedora Extras 5, the rest is pending or in other repos and if other repos count, then ATrpms has several dozens of kmdls :)
I think this argument is invalid. We should ban _all_ module packages from Core and Extras anyway.
On Tue, Aug 15, 2006 at 01:48:05PM +0100, David Woodhouse wrote:
On Tue, 2006-08-15 at 14:34 +0200, Axel Thimm wrote:
An argument against adopting kmdls presented by Thorsten Leemhuis is that
it's too late now to fix it, we should live on with kmod bugs for RHEL5's life-cycle (ending 2012 ...)
too many packages for kmod are written (but actually there is only one in Fedora Extras 5, the rest is pending or in other repos and if other repos count, then ATrpms has several dozens of kmdls :)
I think this argument is invalid. We should ban _all_ module packages from Core and Extras anyway.
That's a valid viewpoint. Assuming Fedora Core/Extras indeed bans all external kernel module packages, does it have the authority/interest to maintain a kernel module packaging guide? If not who should?
On Tue, 2006-08-15 at 14:56 +0200, Axel Thimm wrote:
I think this argument is invalid. We should ban _all_ module packages from Core and Extras anyway.
That's a valid viewpoint. Assuming Fedora Core/Extras indeed bans all external kernel module packages, does it have the authority/interest to maintain a kernel module packaging guide? If not who should?
I think it's probably sane enough for Fedora to maintain a kernel module packaging guide, despite not actually having any such packages for itself.
We understand and expect that there is an ecosystem of other repositories built around Fedora, and it makes sense to have guidelines (and infrastructure in our kernel packages, where appropriate) which make that easier. Especially when that'll be useful for RHEL too.
On Tuesday 15 August 2006 08:48, David Woodhouse wrote:
I think this argument is invalid. We should ban _all_ module packages from Core and Extras anyway.
I'm with David on this one. Packaging of modules is the path to insanity. It requires all kinds of weird hacks to how they are built, how they are named, how they are handled by rpm and depsolvers, they always lag, they always hold users behind when critical kernel fixes come out, etc, etc, etc...
I personally feel (as does David) that if the module isn't good enough for upstream, then it would HAVE to live in the kernel package itself. If it's not good enough for the kernel package itself, then it isn't good enough for Fedora. (Same could be applied to RHEL, but that's a battle for a different list).
Arguing over which ugly ass hack to apply to be able to package kernel modules is a bikeshed argument.
On Tue, 2006-08-15 at 09:27 -0400, Jesse Keating wrote:
Arguing over which ugly ass hack to apply to be able to package kernel modules is a bikeshed argument.
I'm not necessarily suggesting that we shouldn't have an agreed method of building kernel module packages at all -- just that we shouldn't have any such packages in Core or Extras.
There _are_ relatively sane (and legal, unlike nvidia/ati stuff) cases where one might want to build a separate module -- like the NTFS modules in Livna, for example. And other 'new drivers' which aren't yet upstream. Of course you're right when you agree with me that those new drivers shouldn't be in Core or Extras -- but that doesn't mean we shouldn't provide a way to package them at all.
So I think it _is_ worthwhile having the debate about how kernel module packages can be done -- I just don't think it's worth getting _particularly_ worked up about.
On Tuesday 15 August 2006 09:40, David Woodhouse wrote:
I'm not necessarily suggesting that we shouldn't have an agreed method of building kernel module packages at all -- just that we shouldn't have any such packages in Core or Extras.
There _are_ relatively sane (and legal, unlike nvidia/ati stuff) cases where one might want to build a separate module -- like the NTFS modules in Livna, for example. And other 'new drivers' which aren't yet upstream. Of course you're right when you agree with me that those new drivers shouldn't be in Core or Extras -- but that doesn't mean we shouldn't provide a way to package them at all.
Given that we don't want it on Core or Extras, I'm pretty happy to let random 3rd party packager do whatever they want for packaging modules. I'm not interested in dictating how they should handle this ugly hack.
Your example about ntfs is not usable w/out the userland (ntfsprogs), which nobody wants to touch due to legal reasons, and would be obsoleted by FUSE anyway where the most recent ntfs support is done entirely in userspace.
There are many more things the packaging committee can spend time worrying about. Packaging of kernel modules isn't one of them IMHO.
On Tue, 2006-08-15 at 09:50 -0400, Jesse Keating wrote:
Given that we don't want it on Core or Extras, I'm pretty happy to let random 3rd party packager do whatever they want for packaging modules. I'm not interested in dictating how they should handle this ugly hack.
Your example about ntfs is not usable w/out the userland (ntfsprogs), which nobody wants to touch due to legal reasons, and would be obsoleted by FUSE anyway where the most recent ntfs support is done entirely in userspace.
There are many more things the packaging committee can spend time worrying about. Packaging of kernel modules isn't one of them IMHO.
Yeah, that's a fair point. However, it would be useful if those who _do_ care about kernel module packages would come to an agreement about how it should be done, and that can be documented somewhere central to Fedora -- like on the Fedora wiki.
We can modify our kernel RPM and yum if appropriate in order to support that agreed method.
But you're right; the packaging committee don't need to waste time on it.
David Woodhouse schrieb:
On Tue, 2006-08-15 at 09:50 -0400, Jesse Keating wrote:
Given that we don't want it on Core or Extras, I'm pretty happy to let random 3rd party packager do whatever they want for packaging modules. I'm not interested in dictating how they should handle this ugly hack.
Your example about ntfs is not usable w/out the userland (ntfsprogs), which nobody wants to touch due to legal reasons, and would be obsoleted by FUSE anyway where the most recent ntfs support is done entirely in userspace.
There are many more things the packaging committee can spend time worrying about. Packaging of kernel modules isn't one of them IMHO.
Yeah, that's a fair point. However, it would be useful if those who _do_ care about kernel module packages would come to an agreement about how it should be done, and that can be documented somewhere central to Fedora -- like on the Fedora wiki.
We can modify our kernel RPM and yum if appropriate in order to support that agreed method.
That already happend -- FESCo worked out and agreed on a propsoal last winter http://www.fedoraproject.org/wiki/Packaging/KernelModules
It's working fine.
CU thl
On Tue, Aug 15, 2006 at 04:12:06PM +0200, Thorsten Leemhuis wrote:
David Woodhouse schrieb:
On Tue, 2006-08-15 at 09:50 -0400, Jesse Keating wrote:
Given that we don't want it on Core or Extras, I'm pretty happy to let random 3rd party packager do whatever they want for packaging modules. I'm not interested in dictating how they should handle this ugly hack.
Your example about ntfs is not usable w/out the userland (ntfsprogs), which nobody wants to touch due to legal reasons, and would be obsoleted by FUSE anyway where the most recent ntfs support is done entirely in userspace.
There are many more things the packaging committee can spend time worrying about. Packaging of kernel modules isn't one of them IMHO.
Yeah, that's a fair point. However, it would be useful if those who _do_ care about kernel module packages would come to an agreement about how it should be done, and that can be documented somewhere central to Fedora -- like on the Fedora wiki.
We can modify our kernel RPM and yum if appropriate in order to support that agreed method.
That already happend -- FESCo worked out and agreed on a propsoal last winter http://www.fedoraproject.org/wiki/Packaging/KernelModules
It's working fine.
No, it's not, proven in debates on fedora-packaging and here
http://fedoraproject.org/wiki/AxelThimm/kmdls
The proposal you worked out is leading to broken rpm and yum support. That's not working fine.
Axel Thimm wrote:
On Tue, Aug 15, 2006 at 04:12:06PM +0200, Thorsten Leemhuis wrote:
We can modify our kernel RPM and yum if appropriate in order to support that agreed method.
That already happend -- FESCo worked out and agreed on a propsoal last winter http://www.fedoraproject.org/wiki/Packaging/KernelModules It's working fine.
No, it's not...
Thorsten, Axel,
In the hopes of furthering the discussion can we at least agree that the current kmod scheme works, at least to some people's perception of what that means. I hope, also, that we can agree that the current kmod scheme does have limitations/shortcomings.
With that in mind, I think this (should) all boil down to the question: which weighs more heavily in your mind, the pain/suffering(*) of involved in 1. Adopting/changing-to a new (kmdl) standard 2. living with the limitations/shortcomings that come with using kmod. ?
(*) Which brought to my mind one of my favorite movie quotes: "Life is pain, Highness. Anyone who says differently is selling something."
-- Rex
On Tuesday 15 August 2006 11:38, Rex Dieter wrote:
With that in mind, I think this (should) all boil down to the question: which weighs more heavily in your mind, the pain/suffering(*) of involved in 1. Adopting/changing-to a new (kmdl) standard 2. living with the limitations/shortcomings that come with using kmod. ?
3. Kicking kernel module packages out of Core / Extras and moving the debate away from us so that we can focus on the more important things. I vote for #3.
On Tue, 2006-08-15 at 12:11 -0400, Jesse Keating wrote:
- Kicking kernel module packages out of Core / Extras and moving the debate
away from us so that we can focus on the more important things. I vote for #3.
As do I.
"RD" == Rex Dieter rdieter@math.unl.edu writes:
RD> In the hopes of furthering the discussion can we at least agree RD> that the current kmod scheme works, at least to some people's RD> perception of what that means. I hope, also, that we can agree RD> that the current kmod scheme does have limitations/shortcomings.
RD> With that in mind, I think this (should) all boil down to the RD> question: which weighs more heavily in your mind, the RD> pain/suffering(*) of involved in 1. Adopting/changing-to a new RD> (kmdl) standard 2. living with the limitations/shortcomings that RD> come with using kmod. ?
Would the same problems that we have with kernel modules appear with e.g. apache modules, if having two different apache versions installed was possible?
/Benny
On Tuesday 15 August 2006 13:28, Benny Amorsen wrote:
Would the same problems that we have with kernel modules appear with e.g. apache modules, if having two different apache versions installed was possible?
Theoretically yes, however thankfully we don't really let two different apaches be installed.
Dnia 15-08-2006, wto o godzinie 09:27 -0400, Jesse Keating napisał(a):
(...) all kinds of weird hacks to how they are (...) Arguing over which ugly ass hack to apply to be able to package kernel modules is a bikeshed argument.
Isn't the "kmdls" system meant to be the cure to all of this? Is it even a hack? I don't even think the package names are truly ugly.
Fedora is meant to be a testbed of open source technology, right? If so, what's wrong with having separate kernel modules available for me to test and search for bugs? I don't want to patch and compile the kernel only to see if some module works for me. If it's an incomplete device driver, it still can work on my hardware or I can provide some feedback about the features not working. Fedora is packaging lots of broken software which people still want to use (and I'm writing this in Evolution!).
I agree that it's better to make kernel package maintainers to maintain all of patches and additional modules, but they don't have the manpower to do it and support it (not to mention the ones they can't put there, but other repo can).
People are going to make kernel module rpms anyhow. Forcing them to use flawed design that's hard to use, maintain, keep in sync with kernel updates and impossible to boot older kernels is worse than pushing Xorg 7.1 for FC5 which we're not doing because... we recognize the need for people to use off-tree kernel modules :) The Board has spoken - using external kernel modules is a valid user choice and it's important to make it easier for the users. That's my understanding of The Board's decision.
So, kmdls are the next step.
Lam
Leszek Matok schrieb:
Dnia 15-08-2006, wto o godzinie 09:27 -0400, Jesse Keating napisał(a):
(...) all kinds of weird hacks to how they are (...) Arguing over which ugly ass hack to apply to be able to package kernel modules is a bikeshed argument.
[...] So, kmdls are the next step.
Kernel-Module packaging is already working, defined, agreed on by FESCo and used in Fedora Extras. See http://download.fedora.redhat.com/pub/fedora/linux/extras/5/i386/kmod-em8300... for example. The same scheme is used in lvn -- nobody reported problems with it there.
But Axel thinks the scheme FESCo invented (in round about half a year of work) is broken and he thinks his scheme is better.
CU thl
On Tue, 2006-08-15 at 16:06 +0200, Thorsten Leemhuis wrote:
Kernel-Module packaging is already working, defined, agreed on by FESCo and used in Fedora Extras. See http://download.fedora.redhat.com/pub/fedora/linux/extras/5/i386/kmod-em8300... for example. The same scheme is used in lvn -- nobody reported problems with it there.
Did anyone ever provide a good reason for em8300 not being in the upstream or Fedora Core kernels? One which doesn't also prevent it from being in Extras, that is?
Can we drop this package ASAP?
On Tue, Aug 15, 2006 at 04:06:43PM +0200, Thorsten Leemhuis wrote:
Leszek Matok schrieb:
Dnia 15-08-2006, wto o godzinie 09:27 -0400, Jesse Keating napisał(a):
(...) all kinds of weird hacks to how they are (...) Arguing over which ugly ass hack to apply to be able to package kernel modules is a bikeshed argument.
[...] So, kmdls are the next step.
Kernel-Module packaging is already working, defined, agreed on by FESCo and used in Fedora Extras. See http://download.fedora.redhat.com/pub/fedora/linux/extras/5/i386/kmod-em8300... for example. The same scheme is used in lvn -- nobody reported problems with it there.
I'm reproting problems and I wrote a ton of information about the problems. Don't I count?
But Axel thinks the scheme FESCo invented (in round about half a year of work) is broken and he thinks his scheme is better.
Is that wrong to think? And I'm trying to get better tools in the hands of Fedora developers. Is that wrong, too?
On Tuesday 15 August 2006 09:52, Leszek Matok wrote:
Isn't the "kmdls" system meant to be the cure to all of this? Is it even a hack? I don't even think the package names are truly ugly.
I personally find having the kernel version embedded into the NAME of a package is pretty damned ugly. I find it ugly in the compat packages we generate too, but that's a different story for a different day.
Fedora is meant to be a testbed of open source technology, right? If so, what's wrong with having separate kernel modules available for me to test and search for bugs? I don't want to patch and compile the kernel only to see if some module works for me. If it's an incomplete device driver, it still can work on my hardware or I can provide some feedback about the features not working. Fedora is packaging lots of broken software which people still want to use (and I'm writing this in Evolution!).
I agree that it's better to make kernel package maintainers to maintain all of patches and additional modules, but they don't have the manpower to do it and support it (not to mention the ones they can't put there, but other repo can).
People are going to make kernel module rpms anyhow. Forcing them to use flawed design that's hard to use, maintain, keep in sync with kernel updates and impossible to boot older kernels is worse than pushing Xorg 7.1 for FC5 which we're not doing because... we recognize the need for people to use off-tree kernel modules :) The Board has spoken - using external kernel modules is a valid user choice and it's important to make it easier for the users. That's my understanding of The Board's decision.
So, kmdls are the next step.
I still don't buy this argument. kmod and kmdls both fail in the same way without further ugly ass hacks to rpm or depsolvers. I don't buy that kmod makes it impossible to boot older kernels, that's just not the case. I think you're falling for somebody's FUD. I don't like what we have (kmod), I like the proposed "fix" (kmdls) even less. I like the idea of changing one semi broken method for another (even more IMHO) broken method least of all. If we were to make any change, I'd make the change to toss the whole thing out to something external to Core / Extras. Somebody can provide a module if you want to test it out, but I don't think it needs to be let loose upon the users at large until it is ready to either be A) in the kernel source rpm, or B) merged upstream.
On Tue, Aug 15, 2006 at 10:08:11AM -0400, Jesse Keating wrote:
I still don't buy this argument. kmod and kmdls both fail in the same way without further ugly ass hacks to rpm or depsolvers.
kmdl does not need any patch to rpm, while kmod does not work with rpm.
I don't buy that kmod makes it impossible to boot older kernels, that's just not the case. I think you're falling for somebody's FUD.
Read it differently: kmod can only support one kernel.
Either old kernel modules get nuked or they don't get (security) updates, in the latter case you can boot into the old kernel, of course. That's no FUD that's outlined in the wiki. And trying to fix this open a further can of bugs.
kmdls definitely have benefits. All kernels, no matter how old in the queue will get the module updates (if the kernel is still supported in the buildsystem, of course).
On Tuesday 15 August 2006 14:39, Axel Thimm wrote:
kmdl does not need any patch to rpm, while kmod does not work with rpm.
No, kmdl just changes its name every single update to work around the fact that rpm doesn't handle this kind of packaging. This is not a solution, its an ugly hack.
I don't buy that kmod makes it impossible to boot older kernels, that's just not the case. I think you're falling for somebody's FUD.
Read it differently: kmod can only support one kernel.
Wrong.
Either old kernel modules get nuked or they don't get (security) updates, in the latter case you can boot into the old kernel, of course. That's no FUD that's outlined in the wiki. And trying to fix this open a further can of bugs.
I still don't buy that this is a bad thing. We don't want people booting to old kernels unless the new kernel doesn't work. If the new kernel doesn't work, remove it and the modules and you can update your old modules all you want. This isn't perfect, but it is functional. You're using out of the kernel modules, your life is going to suck. Deal with it.
kmdls definitely have benefits. All kernels, no matter how old in the queue will get the module updates (if the kernel is still supported in the buildsystem, of course).
And you need funky hacks to do automated updates, you get new package names all the time to hack around with installation scripts and kickstart scripts, etc... This is not a solution.
On Tue, 2006-08-15 at 14:49 -0400, Jesse Keating wrote:
On Tuesday 15 August 2006 14:39, Axel Thimm wrote:
kmdl does not need any patch to rpm, while kmod does not work with rpm.
No, kmdl just changes its name every single update to work around the fact that rpm doesn't handle this kind of packaging. This is not a solution, its an ugly hack.
As you state, the basic problem is that rpm has a one dimensional view of versions. Proper external kernel module packaging would require two dimensions (version of the kernel and version of the kernel module). A proper solution does not exist.
_Anything_ else is a hack, IMHO.
There are several flavors of hacks. Some work better than others. AFAIK all of them require something else to be changed or modified to try to hide the hack. "Beauty is in the eye of the beholder" so we should probably not talk about "ugly hacks", just "hacks" and their technical shortcomings and/or advantages.
-- Fernando
On Tue, 2006-08-15 at 10:08 -0400, Jesse Keating wrote:
On Tuesday 15 August 2006 09:52, Leszek Matok wrote:
Isn't the "kmdls" system meant to be the cure to all of this? Is it even a hack? I don't even think the package names are truly ugly.
I personally find having the kernel version embedded into the NAME of a package is pretty damned ugly. I find it ugly in the compat packages we generate too, but that's a different story for a different day.
Actually it's not a different story.
It's the same story: Parallel installation.
Ralf
On Thu, 17 Aug 2006, Ralf Corsepius wrote:
On Tue, 2006-08-15 at 10:08 -0400, Jesse Keating wrote:
On Tuesday 15 August 2006 09:52, Leszek Matok wrote:
Isn't the "kmdls" system meant to be the cure to all of this? Is it even a hack? I don't even think the package names are truly ugly.
I personally find having the kernel version embedded into the NAME of a package is pretty damned ugly. I find it ugly in the compat packages we generate too, but that's a different story for a different day.
Actually it's not a different story.
It's the same story: Parallel installation.
Indeed - and to be exact: safely upgradable parallel installation.
We have for example libpng-1.2.8 and libpng10-1.0.18 in FC5. Rpm would allow installing them parallerly if they were just libpng-1.2.8 and libpng-1.0.18 so why do we rename it? To allow them to be upgraded separately, an alleged 'rpm -Uvh libpng-1.2.9' would remove both versions.
I haven't seen anybody arguing we should drop those compat packages and rely on yum plugin to deal with situations like the above correctly... so why are kernel modules any different?
- Panu -
2006/8/17, Panu Matilainen pmatilai@laiskiainen.org:
It's the same story: Parallel installation.
Indeed - and to be exact: safely upgradable parallel installation.
We have for example libpng-1.2.8 and libpng10-1.0.18 in FC5. Rpm would allow installing them parallerly if they were just libpng-1.2.8 and libpng-1.0.18 so why do we rename it? To allow them to be upgraded separately, an alleged 'rpm -Uvh libpng-1.2.9' would remove both versions.
I haven't seen anybody arguing we should drop those compat packages and rely on yum plugin to deal with situations like the above correctly... so why are kernel modules any different?
- Panu -
Because they name it by hand, not by macros, thus is much more reliable. I don't believe in robots either. And a proper name is an artwork.
On Thu, 17 Aug 2006, Yuan Yijun wrote:
2006/8/17, Panu Matilainen pmatilai@laiskiainen.org:
It's the same story: Parallel installation.
Indeed - and to be exact: safely upgradable parallel installation.
We have for example libpng-1.2.8 and libpng10-1.0.18 in FC5. Rpm would allow installing them parallerly if they were just libpng-1.2.8 and libpng-1.0.18 so why do we rename it? To allow them to be upgraded separately, an alleged 'rpm -Uvh libpng-1.2.9' would remove both versions.
I haven't seen anybody arguing we should drop those compat packages and rely on yum plugin to deal with situations like the above correctly... so why are kernel modules any different?
Because they name it by hand, not by macros, thus is much more reliable. I don't believe in robots either. And a proper name is an artwork.
Feel free to not trust in robots. Me, I much rather script the things I can to avoid error-prone manual work, thank you very much.
Anyway, that has little if anything to do with the part that matters here: *why* are the packages renamed.
- Panu -
On Thu, 2006-08-17 at 12:32 +0300, Panu Matilainen wrote:
On Thu, 17 Aug 2006, Ralf Corsepius wrote:
It's the same story: Parallel installation.
Indeed - and to be exact: safely upgradable parallel installation.
We have for example libpng-1.2.8 and libpng10-1.0.18 in FC5. Rpm would allow installing them parallerly if they were just libpng-1.2.8 and libpng-1.0.18 so why do we rename it? To allow them to be upgraded separately, an alleged 'rpm -Uvh libpng-1.2.9' would remove both versions.
I haven't seen anybody arguing we should drop those compat packages and rely on yum plugin to deal with situations like the above correctly... so why are kernel modules any different?
So, why is the kernel any different? Let's identify the differences between the kernel and other packages and then decide whether kernel-modules fit the same criteria as the kernel or normal packages.
-Toshio
On Thu, 2006-08-17 at 11:29 -0700, Toshio Kuratomi wrote:
On Thu, 2006-08-17 at 12:32 +0300, Panu Matilainen wrote:
On Thu, 17 Aug 2006, Ralf Corsepius wrote:
It's the same story: Parallel installation.
Indeed - and to be exact: safely upgradable parallel installation.
We have for example libpng-1.2.8 and libpng10-1.0.18 in FC5. Rpm would allow installing them parallerly if they were just libpng-1.2.8 and libpng-1.0.18 so why do we rename it? To allow them to be upgraded separately, an alleged 'rpm -Uvh libpng-1.2.9' would remove both versions.
I haven't seen anybody arguing we should drop those compat packages and rely on yum plugin to deal with situations like the above correctly... so why are kernel modules any different?
So, why is the kernel any different?
Well, not everybody treats them differently. Mandake and now Mandriva packages their kernels this way:
$ rpm --nosignature -qp --qf "Name: %{name}\nVersion: %{version}\nRelease: %{release}\n" kernel-2.6.12.12mdk-1-1mdk.i586.rpm Name: kernel-2.6.12.12mdk Version: 1 Release: 1mdk
I think I've also seen names like kernel24, kernel26 in some distro(s).
Let's identify the differences between the kernel and other packages and then decide whether kernel-modules fit the same criteria as the kernel or normal packages.
One major difference is the fact that installing / upgrading a kernel doesn't make it's features available runtime by the install/upgrade finishes. It makes things like "if the user asks for nvidia kernel driver installation, for which kernel(s) the driver should be installed for?" less than obvious. Not that this particular difference has much to do with versioning in name or not.
- Panu -
On Tue, 2006-08-15 at 15:52 +0200, Leszek Matok wrote:
People are going to make kernel module rpms anyhow. Forcing them to use flawed design that's hard to use, maintain, keep in sync with kernel updates and impossible to boot older kernels is worse than pushing Xorg 7.1 for FC5 which we're not doing because... we recognize the need for people to use off-tree kernel modules :) The Board has spoken - using external kernel modules is a valid user choice and it's important to make it easier for the users. That's my understanding of The Board's decision.
https://www.redhat.com/archives/fedora-devel-list/2006-August/msg00466.html
"""+ I'm not interested in doing precedent setting with this. The Board made the call that we ultimately felt was best in *this instance* -- we weren't making the decision for all future cases as well."""
-Toshio
Leszek Matok wrote:
Dnia 15-08-2006, wto o godzinie 09:27 -0400, Jesse Keating napisał(a):
(...) all kinds of weird hacks to how they are (...) Arguing over which ugly ass hack to apply to be able to package kernel modules is a bikeshed argument.
Isn't the "kmdls" system meant to be the cure to all of this? Is it even a hack? I don't even think the package names are truly ugly.
Fedora is meant to be a testbed of open source technology, right? If so, what's wrong with having separate kernel modules available for me to test and search for bugs? I don't want to patch and compile the kernel only to see if some module works for me. If it's an incomplete device driver, it still can work on my hardware or I can provide some feedback about the features not working. Fedora is packaging lots of broken software which people still want to use (and I'm writing this in Evolution!).
Nobody is stopping use from using separate kernel modules and we cant dictate what users or other repositories do. This discussion is merely about what Fedora Project should do and having multiple packaging standards is a bad idea to promote.
I agree that it's better to make kernel package maintainers to maintain all of patches and additional modules, but they don't have the manpower to do it and support it (not to mention the ones they can't put there, but other repo can).
If the kernel package maintainers dont have time to maintain them and someone else packages modules in Fedora Extras, the kernel maintainers wont be able to help fix any bugs with these modules loaded. So in essence, we are being self contradictory in this solution.
People are going to make kernel module rpms anyhow. Forcing them to use flawed design that's hard to use, maintain, keep in sync with kernel updates and impossible to boot older kernels is worse than pushing Xorg 7.1 for FC5 which we're not doing because... we recognize the need for people to use off-tree kernel modules :) The Board has spoken - using external kernel modules is a valid user choice and it's important to make it easier for the users. That's my understanding of The Board's decision.
So, kmdls are the next step.
Sorry but the board decision on Xorg 7.1 was for that specific instance. We havent set any general policy on how updates are handled and Max Spevack specifically mentioned that we are not setting any precedent with this decision.
Morever the current kernel module packaging approved by FESCo does not prevent you from booting into older kernels.
Rahul
On Tue, Aug 15, 2006 at 08:15:59PM +0530, Rahul wrote:
Morever the current kernel module packaging approved by FESCo does not prevent you from booting into older kernels.
With the current state of affairs it prevents you to update the kernel modules for your older kernels including security updates.
See pandora's box in http://fedoraproject.org/wiki/AxelThimm/kmdls for the amount of hacks needed to get kmods half-way working and for how much more efforts have to be invested to get them working like kmdls.
Axel Thimm wrote:
On Tue, Aug 15, 2006 at 08:15:59PM +0530, Rahul wrote:
Morever the current kernel module packaging approved by FESCo does not prevent you from booting into older kernels.
With the current state of affairs it prevents you to update the kernel modules for your older kernels including security updates.
... which is very different from what the OP claimed. We really should not be having these discussions in multiple mailing lists.
Rahul
On Wed, Aug 16, 2006 at 12:23:58AM +0530, Rahul wrote:
Axel Thimm wrote:
On Tue, Aug 15, 2006 at 08:15:59PM +0530, Rahul wrote:
Morever the current kernel module packaging approved by FESCo does not prevent you from booting into older kernels.
With the current state of affairs it prevents you to update the kernel modules for your older kernels including security updates.
... which is very different from what the OP claimed. We really should not be having these discussions in multiple mailing lists.
Let's give the OP some truth because the inability to upgrade kernel modules for older kernels imply his statement:
Given that updates of kernel modules for older kernels are not possible, if the kernel module depends on userland (like ipw3495 daemon or a firmware) which get's updated, too (there is s strict matching between ipw2x00 versions and what firmware is allowed), then the old userland package get's updated disabling the kernel module. Or if the kernel module package had a strict depdendency on the userland package it will get removed package-wise, too.
These are two existing examples of how the kmod scheme will indeed nuke you old kernel's wireless support, if the kmdls would had been transformed to kmods. It's not difficult to move the argument to a storage device driver like 3w-9xxx or qla, both of which exist in kmdl form.
kmods are like walking on very thin ice.
On Tue, 15 Aug 2006, Leszek Matok wrote:
Isn't the "kmdls" system meant to be the cure to all of this? Is it even a hack? I don't even think the package names are truly ugly.
Yes, the kmdl system is a hack as well. Having the kernel release in the rpm name is a hack. There are people who would even argue, that such a hack should prvent kmdl from even being considered at all for fedora.
People are going to make kernel module rpms anyhow. Forcing them to use flawed design that's hard to use, maintain, keep in sync with kernel updates and impossible to boot older kernels is worse than pushing Xorg 7.1 for FC5 which we're not doing because... we recognize the need for people to use off-tree kernel modules :)
This is pure and utter BS. The reason for not introducing xorg 7 in fc5 was _not_ that people are using nvidia and ati kernel modules.
Please reread the "closure" thread.
The Board has spoken - using external kernel modules is a valid user choice and it's important to make it easier for the users. That's my understanding of The Board's decision.
Please reread the board's decision as well. Right now, there's quite a lot of discussion on FESCO about these kernel modules. Please read up on the zaptel discussion, it's definitly not clear cut.
So, kmdls are the next step.
Sorry, wrong conclusion.
regards, andreas
On Tue, 2006-08-15 at 09:27 -0400, Jesse Keating wrote:
On Tuesday 15 August 2006 08:48, David Woodhouse wrote:
I think this argument is invalid. We should ban _all_ module packages from Core and Extras anyway.
I'm with David on this one. Packaging of modules is the path to insanity. It requires all kinds of weird hacks to how they are built, how they are named, how they are handled by rpm and depsolvers, they always lag, they always hold users behind when critical kernel fixes come out, etc, etc, etc...
Sorry. No. Not "always". Always is _always_ too strong a word, oh well, perhaps not? :-) ;-) :-)
ALSA: I've been packaging ALSA kernel modules for years for the Planet CCRMA project (since 2001). Bumped my head against many walls in the process. Examined kernel packaging proposals that sounded fine till you used them and found they did _not_ work. I packaged kernel modules first out of necessity because the kernel did not include ALSA at all. Then also out of necessity to get newer versions of the ALSA kernel modules than the ones in the standard kernel tree - or modules for soundcards that have not made it to the kernel tree yet but are usable (and no, waiting for them to make it to the standard tree is not always an option).
I'm not arguing for or against including kernel modules in extra or core or rhel or whatever - but there should be a solid guideline on how to package them that works. With proper support in resolvers, kernel infrastructure, etc[*]. If the current one has flaws (it does!) then let's fix them. The need exists, it is part of reality, denying reality will not make it dissappear (that's at least my experience over the years).
I'm still using in Planet CCRMA a scheme similar to the one proposed. It works.
-- Fernando
[*] even support for the kernel itself has problems - if I have a kernel that is version-release older than the latest kernel I _can not_ install it using an unpatched yum.
I personally feel (as does David) that if the module isn't good enough for upstream, then it would HAVE to live in the kernel package itself. If it's not good enough for the kernel package itself, then it isn't good enough for Fedora. (Same could be applied to RHEL, but that's a battle for a different list).
Arguing over which ugly ass hack to apply to be able to package kernel modules is a bikeshed argument.
On Tue, 2006-08-15 at 14:34 +0200, Axel Thimm wrote:
Hi all,
there is currently a discussion about replacing the current kernel module scheme ("kmod") with a new one ("kmdls"). This is because the current scheme has some unfixable flaws. The proposed new scheme is the one used at ATrpms, so if you ever used a kernel module package from there you know how it is setup.
The kmdl approach has several nice features other than being resistant to the design issues of the current setup.
It is an interface/implementation design that can actually even be used for the current (broken) setup. The specfile remains invariant.
It uses one specfile/src.rpm for both userland and kernel modules, e.g. one set of sources/patches/changelogs/bugzilla entries/owners.
It is kernel and kernel-flavour agnostic, the same specfile/src.rpm can be used for any kernel/flavour combination, even for such that are yet to come.
Has full yum-support with a 99-line python plugin, works even w/o the plugin with a couple more keystrokes.
Is field-proven for several years and managed to never have to change the interface!
More details are on http://fedoraproject.org/wiki/AxelThimm/kmdls
It is important for FC6 and RHEL5 to make a decision on adopting it. Currently GFS is being packaged in the old scheme which is known to exhibit several flaws.
An argument against adopting kmdls presented by Thorsten Leemhuis is that
- it's too late now to fix it, we should live on with kmod bugs for RHEL5's life-cycle (ending 2012 ...)
Fedora is _not_ RHEL. Period. If they happen to use the same packaging scheme for modules, fine. That doesn't mean that Fedora cannot change it's standards during a particular RHEL's lifetime.
Therefore, I see no urgency in getting this changed. If kmdls is truly a better way, then it can be adapted when it has been fully discussed.
josh
On Tue, Aug 15, 2006 at 07:51:48AM -0500, Josh Boyer wrote:
An argument against adopting kmdls presented by Thorsten Leemhuis is that
- it's too late now to fix it, we should live on with kmod bugs for RHEL5's life-cycle (ending 2012 ...)
Fedora is _not_ RHEL. Period. If they happen to use the same packaging scheme for modules, fine. That doesn't mean that Fedora cannot change it's standards during a particular RHEL's lifetime.
I agree that Fedora is not RHEL and vice versa. But once any idiom is adopted into one of the two the other will have a very hard time to get by, the bar is raised quite a bit.
Whether we like it or not (BTW I like it) the two distributions are closely related and influence each-other.
Therefore, I see no urgency in getting this changed. If kmdls is truly a better way, then it can be adapted when it has been fully discussed.
GFS is in FC6, too. Only the life-span of FC6 is shorter. Furthermore yum developers want to know what scheme will need to be supported. As argued in the wiki yum support for the current scheme is an endless story, while the new proposed scheme already has it's fully working plugin submitted.
Do you really want to see developers burn more time in a lost cause? We could be using that developer time elsewhere.
Once upon a time, Axel Thimm Axel.Thimm@ATrpms.net said:
GFS is in FC6, too.
GFS in FC6 is included in the kernel package, not as an external module, so kmod vs. kmdls doesn't apply.
There are currently no externally packaged kernel modules in Fedora Core or Extras development trees.
On Tuesday 15 August 2006 09:06, Chris Adams wrote:
There are currently no externally packaged kernel modules in Fedora Core or Extras development trees.
+2 in cvs that are not build ATM (thinkpad-lkmod and lirc-kmod)
+7 under review
+6 in (some other repo), and yes that (some other repo) uses the same packaging guidelines.
+2 in RHEL5 (yes RHEL uses the same guidelines)
On Tue, Aug 15, 2006 at 08:06:11AM -0500, Chris Adams wrote:
Once upon a time, Axel Thimm Axel.Thimm@ATrpms.net said:
GFS is in FC6, too.
GFS in FC6 is included in the kernel package, not as an external module, so kmod vs. kmdls doesn't apply.
That's GFS2 you're talking about. GFS(1) still lives external to the kernel and has a different on-disk format so it isn't superseeded by GFS2, in fact every FC4/FC5 install using GFS needs this module to be in there when FC6 gets released.
There are currently no externally packaged kernel modules in Fedora Core or Extras development trees.
There is one in Fedora Extras 5 (em8300) and GFS is in a bugzilla review (#201077).
But agreed, there aren't that many kmods out there so it's really not too late nor too much work to convert them to something better.
-
Andreas Thienemann -
Axel Thimm -
Benny Amorsen -
Chris Adams -
David Woodhouse -
Fernando Lopez-Lezcano -
Jesse Keating -
Josh Boyer -
Leszek Matok -
Panu Matilainen -
Rahul Sundaram -
Ralf Corsepius -
Rex Dieter -
Thorsten Leemhuis -
Toshio Kuratomi -
Yuan Yijun