[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



> 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. 

I'd scrap it. I started packaging alsa a while ago (Jun 2000) and always
modeled the packages on the way the kernel itself is packaged (ie: smp
is separated from up and has an -smp in in the name). 

> start the discussion again here -- maybe redhat employees and especially
> yum, apt and up2date programmers can give input. 
>
> 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.

I know, but that is the way the kernels themselves are packaged. 

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

I had not thought of this issue. Again, I would prefer naming the
packages with the same convention as the kernels. The information has to
be there in any case, and I simply prefer it to match the way it is
displayed in the kernel packages (just a matter of opinion). 

I also like listings where the modules are alphabetically sorted next to
the packages they belong to (alsa-kernel-module is part of the "alsa"
set of packages, not to the kernel, at least IMHO :-), but again that is
a personal preference. Others prefer all the kernel modules to be sorted
together (kernel-module-alsa). The first option sounds better to me, but
that's just me. It is not a substantial difference. 

> - 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. 

At least for apt (in my experience) you need something else to ensure
that the kernel modules that apt installs match both the kernel and its
architecture. I had a LOT of problems in my user base with ALSA installs
(through apt) where the kernel module picked by apt would match the
kernel but _not_ its architecture. So, "I have unresolved symbols" would
echo again through the mailing list. 

I don't know where the problem is (rpm and/or apt) but the problem is
real and should be solved. 

I resisted for a while but finally ended up including a special
"Provides:" in my low latency kernels that includes the kernel version
_and_ its architecture (Axel Thimm ended up doing exactly the same
thing, albeit with different naming conventions - we were going to try
to unify into just one). A matching "Requires:" in the alsa kernel
module packages makes it possible to always get it right. 

Including a proper "Provides:" in the Fedora Core kernels would be great
and would have zero impact other than making sure the proper module
package always gets installed. 

For example in my latest up kernel I have this:
  Provides: kernel-version-%{_target_cpu} = %{version}-%{release}

> - 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. 

Agreed. 
-- Fernando





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]