Kernel module packages (was - Re: Pre-Review: Asterisk)

[Tom 'spot' Callaway]

On Sat, 2005-04-02 at 15:17 -0700, Michal Jaegermann wrote:
> On Sat, Apr 02, 2005 at 12:05:19PM -0600, Tom 'spot' Callaway wrote:
> > 
> > Unfortunately, there is no sane way to deal with kernel-module addon
> > packages yet.
> .....
> > 
> > There are several ways to hack around this issue. We could make each
> > package have a unique name by cramming the kernel uname -r in the addon
> > package name,
> 
> External kernel modules are a given kernel specific.  One would
> think that should be reflected in a package name, or maybe better
> "identifier", or otherwise you have quick descent to madness in a
> system maitenance.

I agree. External modules are a given kernel specific. They should
identify which kernel they are for.

However, this should not be done in %{name}. Version is a more
appropriate place for this.

So, we would have:

Name: kernel-module-foo
Version: 2.6.10_3smp
Release: 1

> It does not seem to be good enough in this form.  If you happen to
> have kernels 2.6.10-%{release} and 2.6.10-%{release+1} installed in
> parallel then you need modules for both.  You may also have smp and
> non-smp and maybe something more.

I think I oversimplified the example to show the point. :)

> Or you mean different releases of
> module packages for the same kernel?

Yes. Let me expand on my example.

I have three kernel packages installed:

kernel-2.6.10-2
kernel-smp-2.6.10-2
kernel-2.6.10-3

Each of these has a kernel-module-foo package installed alongside it:

kernel-module-foo-2.6.10_2-1
kernel-module-foo-2.6.10_2smp-1
kernel-module-foo-2.6.10_3-1

Now, I (being the illustrious maintainer of kernel-module-foo) discover
a nasty bug in the source, which I fix, and want to push a new release
of the package, -2.

I create the following new packages:

kernel-module-foo-2.6.10_2-2
kernel-module-foo-2.6.10_2smp-2
kernel-module-foo-2.6.10_3-2

But now, when I hand these to rpm, what do I do?

If I try to perform a -i, kernel-module-foo is already installed.
If I try to perform a -U, kernel-module-foo conflicts with
kernel-module-foo, it upgrades the largest item, and get rid of all the
other kernel-module-foo packages it sees. Which leaves us with only
kernel-module-foo-2.6.10_3-2 installed.

As I said before, we can skirt this problem if we overload the %{name}
and put the kernel version there. However, this means that in CVS, we'd
have separate branches for every possible kernel version, bugzilla would
have entries for every possible kernel version. Its bad, and we
shouldn't do it.

We need to teach rpm to perform the following transaction (ignoring
normal dependency checks):

- package kernel-module-foo-2.6.10_2-1, kernel-module-foo-2.6.10_2smp-1,
and kernel-module-foo-2.6.10_3-1 are installed (-i will permit this).
- user asks for packages kernel-module-foo-2.6.10_2-2,
kernel-module-foo-2.6.10_2smp-2, and kernel-module-foo-2.6.10_3-2 to be
installed.
- rpm looks for existing packages which match %{name}-%{version} for
each of these pending update packages.
 - if found, then compare %{release} with that existing  
   %{name}-%{version} package
  - if %{release} of pending update is greater than existing, then 
    upgrade ONLY that existing package with same %{name}-%{update}
  - else, if %{release} of pending update is same as existing, then 
    compare epoch
    - if epoch of pending update is higher, then upgrade ONLY that 
      existing package with same %{name}-%{update}
  - else, if %{release} of pending update is lower than existing, then 
    exit with error.
 - else, if not found, perform standard -i operation on pending update 
   package.

Does that make it more clear? :)

~spot
-- 
Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!