[Fedora-packaging] Kernel Module Packages

[Andreas Gruenbacher]

On Friday 19 August 2005 01:00, Tom 'spot' Callaway wrote:
> On Fri, 2005-08-19 at 00:16 +0200, Andreas Gruenbacher wrote:
> > My example was not perfectly well chosen. The idea was to have provider
> > prefixes like adaptec, nvidia, ati and similar, so an example out-of-line
> > aic7xxx upgrade would be adaptec-aic7xxx-8.9.10-2.6.13_99_smp-3, etc.
>
> I don't see it serving any purpose. I don't want to have a field that
> people are trying to shoe-horning ugliness into. This just opens the
> door to rpms with horrible provider prefixes, and rpms with %{name}:
>
> InternationalBusinessMachinesJapanCOPYRIGHT2005ALLRIGHTSRESERVED-mwave-3.14
>15972-2.6.13_99_smp
>
> ... when all we really need is:
>
> kernel-module-mwave

Great, thanks for the thoughtful example. I was talking about a prefix from 
the LANANA provider name registry, 
http://lanana.org/lsbreg/providers/index.html, and I'm also aware that many 
potential providers don't have an entry there, yet. Also see 
http://lsbbook.gforge.freestandards.org/lanana.html about LSB's package 
naming recommendations.

The two proposals, next to each other, and even for the same example, seem to 
be:

  Name:      kernel-module-aic7xxx
  Version:   6.2.36
  Release:   1.2.6.13_rc6_1_smp

vs.

  Name:      adaptec-aic7xxx-6.2.36
  Version:   2.6.13_rc6_1_smp
  Release:   1

> > > > The driver name, driver version, and kernel release ($KERNELRELEASE)
> > > > are also stored differently in rpm tags: our build system likes to be
> > > > able to freely assign the package release number, so we don't store
> > > > extra information there. Rather, we put the driver version in the
> > > > Name, and the kernel release in the Version:
> > >
> > > Hmm. Again, I don't want to overload %{name}. That's not what its there
> > > for, imho.
> >
> > What makes %version or %release more appropriate for overloading? With
> > the driver version as part of %version or %release, you can't easily
> > offer packages for more than one version of a driver for the same kernel,
> > and yet have working updates. I would be surprised if you didn't ever
> > have this situation with RHEL.
>
> Users won't expect to have the name be overloaded. Users want to search
> for "kernel-module-foo", query the rpmdb for kernel-module-foo. Not to
> mention the nightmare of tracking it in bugzilla, and generating massive
> amounts of unnecessary SRPMs.

Putting aside FUD for a second, where do you see problems querying the rpm 
database, or in Bugzilla? And why do you think the number of source rpms 
would change at all?

> And we can certainly offer multiple packages.
>
> kernel-module-foo-1.2-1.2.6.13_93smp (driver version 1.2, build 1)
> kernel-module-foo-1.2-2.2.6.13_93smp (driver version 1.2, build 2)
> kernel-moudle-foo-1.3-1.2.6.13_93smp (driver version 1.3, build 1)

You can have multiple packets next to each other, but rpm --freshen (and other 
tools using the same logic) won't work as expected anymore: you will always 
end up with the most recent driver version. Sticking with the same driver 
version by default will break.

-- Andreas.