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

Re: [Fedora-packaging] Re: DKMS into Fedora Extras



On Tue, 2005-02-22 at 10:00 -0500, seth vidal wrote:
>> I think you missed my logic for this case.  If there would be an
>> update for a kernel-module, and the update has the same Requires: as
>> an existing installed kernel-module of the same name, then replace the
>> installed one with the new one, but don't touch any others that have
>> Requires: for a different kernel.  
>
>and I think you missed my point:
>rpm can't do that.

OK, so if rpm isn't smart enough to do that, can we teach yum to deal
with this case?

If new package is of type "foo" (where foo is kernel-module in this
case), check for existing installed package of the same name. If exists,
rpm -e existing, then rpm -ivh new package. (yes, i realize this is a
bit icky, but this case is nasty as is)

Hopefully, nothing is depending on a kernel-module package (we can
always enforce this by saying anything that DOES depend on a
kernel-module package should be packaged with it).

How many kernel-module packages are we really considering here?

openafs: include the tools and the kernel module in the same package
unionfs: ditto

Now, assuming that livna wants to use the same mechanism, there are
several other binary-only modules (ati & nvidia drivers), but no other
packages should be depending on them.

And when we remove the kernel-module rpm, the driver is either loaded or
not. If loaded, its resident in memory, and the user can rmmod it and
reload if they want to avoid a reboot. If not, we're fine.

thoughts?

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