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.
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.
This one has come out of left-field to me. Nobody AFAIK has previously proposed throwing out kernel modules altogether. I also don't think it makes sense because, notwithstanding the RPM problems, there are plenty of useful kernel modules that exist and are maintained (for various reasons, good or bad, right or wrong) outside the kernel tree. I don't see why kernel modules are any less useful than other random FE packages, just because they're in kernel space. FE is supposed to be a maximal set of software, right? That's at odds with a rule disallowing any kernel modules. Why shouldn't kernel modules be included, exactly? Excluding them just because of the problems with packaging seems rather like throwing the baby out with the bath water.
FWIW, although the kmod stuff seems "nicer" in a way, I've been relatively convinced by what Axel has had to say about kmdl. They're both trying to make the best of a bad job; kmdl seems to have slightly fewer problems.
And for those that say RHEL is nothing to do with Fedora: true theoretically, but if you look at:
a) the number of Fedora devs who are RH employees
b) the number of Fedora users who also use/build packages for RHEL and derivatives either for work, fun or both
then I think it's worth at least *considering* the potential annoyance/confusion of RHEL/Fedora having two different schemes.
Regardless of the outcome I'd like to thank Axel in particular and all the other contributors to the debate so far for their time and energy. I don't think anyone finds this stuff terribly exciting as I think we'd all rather be *using* packages than debating the finer details of which packaging scheme is better than another, but this stuff is important in the big picture both of getting the best technical solution and making Fedora the best distro with a wide choice of well-packaged software. Whilst we shouldn't pander to any special interest, I do believe it's in all our interests to at least pay serious attention to the input from well-established third party contributors like Axel who have done so much in the past few years to bring a large base of add-on software to RHL/RHEL/Fedora. They have very useful practical experience of various techniques applied to a relatively large audience and this knowledge (and established packages) can only benefit Fedora.
Tim
On Tuesday 15 August 2006 17:42, Tim Jackson wrote:
This one has come out of left-field to me. Nobody AFAIK has previously proposed throwing out kernel modules altogether.
David Woodhouse proposed it weeks ago. I've gotten tired enough of this discussion and noticed the ways that BOTH methods suck arse that I'm inclined to agree with David that packaging of kernel modules is just not something an RPM based distro is capable of handling in a clean way. There are more philosophical reasons to not allow kernel modules, but I go into that.
I also don't think it makes sense because, notwithstanding the RPM problems, there are plenty of useful kernel modules that exist and are maintained (for various reasons, good or bad, right or wrong) outside the kernel tree.
This doesn't mean there are room for them in the Fedora project. Bad reasons should be fixed. Good reasons (like illegal to be in kernel or closed source) are unacceptable for the Fedora project. Once free, always free.
I don't see why kernel modules are any less useful than other random FE packages, just because they're in kernel space. FE is supposed to be a maximal set of software, right?
No, a maximal set of ACCEPTABLE and non-forbidden software that can be maintained. There are "useful" things that aren't acceptable. Certain encryption methods due to US restrictions on the exporting of them. Emulators are not acceptable. Some forms of content are not allowed either:
*
Comic book art files *
Religious texts *
mp3 files (patent encumbered)
That's at odds with a rule disallowing any kernel modules. Why shouldn't kernel modules be included, exactly? Excluding them just because of the problems with packaging seems rather like throwing the baby out with the bath water.
Technical reasons: By nature they always lag. They will prevent a user from being able to update to new kernels, which could prevent them from getting critical security fixes. Without hand deselecting packages for updates, this could also prevent ANY updates from being applied. Worse, the updates (and new kernel) could be installed and the module would not be available, preventing the system from functioning.
Supportability. External modules can and do introduce bugs into the running kernel. They can have adverse but hard to realize problems in a running system. The kernel gets the blame, and bugzilla gets overrun with false reports that have nothing to do with the kernel rpm, and everything to do with the addon module. Expecting the kernel maintainer to sort these out and triage takes away from his/her precious time.
These are a couple really good reasons in my book to not allow it.
On Tue, 2006-08-15 at 18:03 -0400, Jesse Keating wrote:
No, a maximal set of ACCEPTABLE and non-forbidden software that can be maintained. There are "useful" things that aren't acceptable. Certain encryption methods due to US restrictions on the exporting of them. Emulators are not acceptable. Some forms of content are not allowed either:
* Comic book art files * Religious texts
Doesn't FE have sword & gnomesword in it? Based on it's description it sounds like it contains religious text.
/B
On Tue, 2006-08-15 at 19:14 -0400, Brian Pepple wrote:
On Tue, 2006-08-15 at 18:03 -0400, Jesse Keating wrote:
No, a maximal set of ACCEPTABLE and non-forbidden software that can be maintained. There are "useful" things that aren't acceptable. Certain encryption methods due to US restrictions on the exporting of them. Emulators are not acceptable. Some forms of content are not allowed either:
* Comic book art files * Religious textsDoesn't FE have sword & gnomesword in it? Based on it's description it sounds like it contains religious text.
... And these had been an issue when they had been under review.
Ralf
On Wed, 2006-08-16 at 11:20 +0200, Ralf Corsepius wrote:
On Tue, 2006-08-15 at 19:14 -0400, Brian Pepple wrote:
Doesn't FE have sword & gnomesword in it? Based on it's description it sounds like it contains religious text.
... And these had been an issue when they had been under review.
Yeah, looks like this was approved for FE back when we were doing reviews on the mailing list. Do these packages need to be looked at again to make sure that they should be in FE? I actually haven't used them, so I'm not sure if they actually contain forbidden content.
/B
"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.
packaging@lists.fedoraproject.org
-
Axel Thimm -
Benny Amorsen -
Brian Pepple -
Jesse Keating -
José Abílio Matos -
Ralf Corsepius -
Rex Dieter -
Thorsten Leemhuis -
Tim Jackson