Nameing guideline for external kernel-modules in fedora(.us)

[Thorsten Leemhuis]

Hi,

I'm currently trying to build FC1 alsa-packages for the fedora.us
repository. library and utils are ready, oss, tools and firmware loader
are in the works. 

The kernel-driver is also mostly ready, but we're currently a bit
undecided how the resulting package with the kernel-modules should be
named. Also a problem: What package or files should it provide and what
should it require? For details see
http://bugzilla.fedora.us/show_bug.cgi?id=601

The fedora.us guidelines currently recommend to build a package per arch
which contains the modules for both UP and SMP kernel. Until now all
packages in fedora.us were AFAIK only for UP so alsa would be the first
and some people now wonder if this decision was right. So I'd like to
start the discussion again here -- maybe redhat employees and especially
yum, apt and up2date programmers can give input. 



---
Some background of the current state:

Fedora.us: Current Package Naming Guidelines:
http://www.fedora.us/wiki/PackageNamingGuidelines
(kernel-modules nameing is in section C5)

Freshrpms names the packages:
kernel-smp-module-alsa-1.0.0-0.rc2.1.fr_2.4.22_1.2129.nptl.i686.rpm
kernel-module-alsa-1.0.0-0.rc2.1.fr_2.4.22_1.2129.nptl.i686.rpm

atrpms names the packages:
alsa-kmdl-smp-2.4.22-1.2129.nptl-1.0.0-rc2_17.rhfc1.at.i686.rpm
alsa-kmdl-2.4.22-1.2129.nptl-1.0.0-rc2_17.rhfc1.at.i686.rpm

dag names them like this (no alsa-packages seen)
kernel-module-openafs-1.2.9-0_2.4.20_19.9.dag.rh90.athlon.rpm  
kernel-smp-module-openafs-1.2.10-0_2.4.20_20.9.dag.rh90.athlon.rpm

Some interesting mails I've found (there are a lot more and this will
mail will result in even more):

fedora.us, kernel module packaging standard - RFC 1:
http://www.fedora.us/pipermail/fedora-devel/2003-March/000364.html
fedora.us, Kernel module package proposal:
http://www.fedora.us/pipermail/fedora-devel/2003-March/000662.html
fedora.us, kernel-module-* standards discussion:
http://www.fedora.us/pipermail/fedora-devel/2003-May/001279.html
yum-list,kernel module distribution via yum:
https://lists.dulug.duke.edu/pipermail/yum/2003-July/001619.html
yum-list, Building kernel modules:
https://lists.dulug.duke.edu/pipermail/yum/2003-July/001604.html



---
My proposal (cust my 2 cent):

kernel-module-_DRIVER-NAME_-$(uname -r)-%Version-%Epoch.%Release

results in

kernel-module-alsa-2.4.22-1.2129.nptl-1.0.0-0.fdr.0.2.rc2.athlon.rpm
kernel-module-alsa-2.4.22-1.2129.nptlsmp-1.0.0-0.fdr.0.2.rc2.athlon.rpm



---
Why: 
- Starting the kernel-modules-packages with the name

kernel-modules

is IMHO clear and nice. Name the SMP-Packages

kernel-smp-modules
or
kernel-modules-smp

is IMHO not needed -- this information is redundant if we place the
kernel version in form of the output of an "uname -r" in the package
name in any case.

bigmem or other kernel-tags would raise to name problems again (like
kernel-smp-bigmem-modules or kernel-smp-modules)?

- Including the "uname -r" in the package name is somewhat complicated
but maybe the est way -- an Update of the kernel would require a update
from a package
kernel-module-alsa-2.4.22-1.2115.nptl
to the package named
kernel-module-alsa-2.4.22-1.2129.nptl
Apt, Yum and and up2date would need to take special care of it during
upgarde of the main kernel -- but they need special things for
kernel-updates in any case already (AFAIK). BTW: This way allows us to
install kernels and their matching modules in parallel. 

- Placing SMP modules and UP per arch in one package is IMHO not a good
idea. I currently don't see any advantage of this scheme. It would waste
hard-disk space and designing the Spec-File so rebuilding the source rpm
with a self-compiled kernel would be harder to archive (I think).


----
CU and thanks for listening
thl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20031212/ca781b4d/attachment.sig>