RFC: kernel-modules in Fedora Extras

[Thorsten Leemhuis]

Am Samstag, den 07.01.2006, 08:31 -0600 schrieb Josh Boyer:
> On Fri, 2006-01-06 at 11:30 +0100, Thorsten Leemhuis wrote:
> > 
> > The most important rule for packages with kernel modules: There are
> > always at least two SRPMS -- one builds a userland package (tools,
> > documentation, license, udev configuration etc) of the source, the other
> > builds packages with *only* the kernel-module(s). The packager is free
> > to split the userland-package further into one with a the general 
> > userland parts, that works fine without the kernel-modules, one with
> > the kernel-module related parts and one with the kernel-module(s). 
> > The userland package with the parts that are related to the
> > kernel-module(s) must follow follow the standard guidelines for Fedora 
> > Extras packages with one additional rule:
> > - MUST: The package needs to require the belonging kernel-module
> >   with something like "Requires: kmod-%{name} = %{version}"
> 
> What happens if a driver gets merged into the kernel upstream?  Or if
> davej et. al decide to put it in the Core kernel package for one reason
> or another?  Will the Core kernel package now have to have a
> Provides/Obsoletes: kmod-%{name} ?

No, I don't think this is necessary. The userland-package should be
modified from
Requires: kmod-%{name} = %{version}
to
Requires: kernel >= 2.6.15
or
Conflicts: kernel <= 2.6.14

and rebuild and pushed after that. In an ideal world that should happen
exactly at the same time the updated kernel is released.

And with the next release of Core the userland-package probably needs to
be dropped cause all parts (udev rules for example) often are a part of
core then. The question is: what obsoletes the package so it gets
removed? fedora-release?

> Cases like this probably won't come up all that much

I hope they will -- kernel-module authors should get their modules
upstream. As soon as possible.  Look for the current mess with WLAN
drivers -- it's getting better now, but still is far from perfect. Or
ivtv. Or special I2C-patches for DVB and V4L2 that don't work together.

Shipping GPLed kernel-modules in Fedora Extras should therefor only be a
interim solution for a kernel-module. The packager should make it as
clear as possible to the module author that he should get his code
merged with the upstream kernel. As soon as possible. (ohh, sorry, I did
say that already ;-) )

We were even discussing a time-limit how long GPL-Modules are allowed to
stay in extras (e.g. 18 or 24 months) until they either have to be
merged with the kernel or dropped from extras. But we dropped the idea. 

>[...]
> > Besides rules around the packaging there is one additional *before*
> > you start packaging a kernel module for Fedora Extras: Open a Review
> > bug in http://bugzilla.redhat.com and ask FESCo for permission if this
> > module is allowed for Extras. This requires that you give at least the 
> > following informations:
> > - Name of the package
> > - URL of the project and a tarball of the latest version
> > - License
> > - A publishable explanation from the author(s) why the module is not
> >   merged with the mainline kernel yet and when it's planed to get
> > merged. You of course can ask the author to explain it directly in the
> > bug report.
> 
> 
> > Why all this?
> > - The Fedora Project wants to encourage driver developers to merge their
> >   sources in the kernel
> > - It easier for everyone if the modules are in the main kernel
> > - There is often a good reason why the kernel developers refuse to merge
> >   a driver. If it's not good enough for the kernel, why should it be 
> >   good enough for Fedora?
> > - Most modules that are maintained independently of the kernel have
> >   licensing issues that also make it impossible to ship them in Fedora 
> >   Extras.
> 
> There are some modules out there that have no intentions of merging into
> upstream, such as openAFS.  That fact alone shouldn't be a reason to not
> package it for Extras.

Of course. Hey, I even choose to work on the openafs packages ;-) (see
other mail in this thread).

But a lot of modules that are not part of the kernel were not yet merged
for reasons that also make them not suitable for Fedora Extras.

CU
thl
-- 
Thorsten Leemhuis <fedora at leemhuis.info>