[elrepo-devel] Deprecating packages

Phil Perry phil at elrepo.org
Sat Mar 6 15:38:08 EST 2010


Hi all,

I've recently gone through the backported /hwmon tree in RHEL5.5b1 and 
done diffs against our kmods to identify packages we should deprecate in 
favour of newer/same kernel modules (more on that later).

My brief list of packages I'll be deprecating upon RHEL5.5 release:

adt7473
pc87427
vt1211

This raises the question of how we go about deprecating an elrepo kmod.

On IRC we briefly discussed a few options:

1. Announce to the ML that the package is deprecated and recommend the 
user 'rpm -e kmod-foo' removes the package in favour of the kernel 
module (as of kernel > X)

2. Release a self-destructing kmod update.
Release an updated package with Requires kernel > 2.6.18-xyz.el5 (so 
that users staying with older kernels don't get the update) that doesn't 
contain the .conf override and thus allows the kernel module to become 
the default.

3. Release an update identical to the driver in RHEL.
This doesn't appear to solve the issue, only delays it - the same issue 
arises when the driver gets updated down the line.

Opinions?

I'm really not in favour of releasing packages that mess with users 
system and as such I see no alternative to option 1. IMHO we should not 
try to manage end users systems for them. If an admin has installed a 
3rd party driver then they should take responsibility for managing that 
and keeping it updated. Therefore I think option 1 is an acceptable 
solution.




More information about the elrepo-devel mailing list