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

Re: Pre-Review: Asterisk



On Sat, 2005-04-02 at 12:47 -0500, Rik van Riel wrote:
> On Sat, 2005-04-02 at 08:28:08 -0600, Jeffrey C. Ollie wrote:
> 
> > So, until such time as the Zaptel drivers get into the stock kernel, I'd 
> > like to have the drivers packaged separately.
> 
> Agreed, it's better to have the drivers in Fedora Extras
> for now, than not at all - and carrying around tons of
> extra drivers in the Fedora Core kernel just isn't going
> to happen, there are enough patches already ;)

Unfortunately, there is no sane way to deal with kernel-module addon
packages yet. Ville has been working pretty hard to cover some of them,
but there is still at least one big issue:

We can't cleanly upgrade kernel-module addon packages without scorching
the earth. This is pretty vital, if we ever want to fix bugs in addon
drivers without waiting for the next kernel to come out.

Lets say that we have two kernel packages installed, and two
kernel-module-afs packages that match them. Then we need to upgrade the
kernel-module-afs packages. Problem is that we can't use -i or -U here.

-i won't work because there are already installed versions.
-U won't work because it will remove all existing versions and try to
put in one kernel-module-afs package (rather than updating them both
like we want).

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, but thats hideous. It breaks all our ownership, bugzilla,
and CVS infrastructure.

We could build in a horrible workaround inside yum, but then we'd need
to do the same for every packaging delivery system that people want to
use (yum, apt, smart, etc).

Rpm really needs to be able do this natively.

Kernels get installed with -i today. kernel-module-* needs to get
installed with a new mode, where if kernel-module-foo-2.6.10-%{release}
is installed, and kernel-module-foo-2.6.10-%{release+1} exists, then
only kernel-module-foo-2.6.10-%{release} gets upgraded (and not
kernel-module-foo-2.6.9-%{release}, unless an upgrade for it exists, and
yum/apt/whatever can take care of it then, using the same mechanism).

Sortof a "upgrade only the installed package with the same %{version}"
flag. -S for same. :)

If no installed package with the same %{version} exists, fallback to -i
logic.

Let the %{version} be the kernel version.

I haven't had the time to even start looking at rpm's code to work on
making this possible, but its a safe bet that we won't have this done by
FC4, unless people start hacking it right now.

Is anyone interested in taking this challenge up?

~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!


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