[elrepo-devel] Deprecating packages

[Phil Perry]

Akemi Yagi wrote:
> On Sat, Mar 6, 2010 at 12:38 PM, Phil Perry <phil at elrepo.org> wrote:
> 
>> 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'd really like to find a clean way of removing obsoleted (no longer
> needed) packages without human intervention if possible.  Unlike
> regular packages, kABI-tracking kmods, once installed, will continue
> to exist and the module gets symlink'd upon every kernel update until
> the kABI breaks. And the (obsolete) module would take precedence over
> the in-kernel module.
> 
> So, another potential (but obviously not the best) solution might be
> to release an update that reverts the priority defined in
> /etc/depmod.d/*.conf.
> 

I guess what you're looking for is a way to allow kmod-foo to override
some kernels but not others. As it stands, /etc/depmod.d/foo.conf is an
all or nothing override for that module.

Your suggestion to revert the priority defined in /etc/depmod.d/foo.conf
is essentially option 2 above. The issues with such an approach as I see
it are that the kmod will get silently disabled when updated which is
not what users on older kernels will want, so you add a Requires for the
latest (el5.5) kernel at which point yum update complains about missing
requires for 2-3 months until the EL clones (CentOS, SL) catch up and
release their el5.5 products. All rather messy IMHO.

So how about instead adding:

Conflicts: kernel >= 2.6.18-186.el5

or whatever el5.5 final kernel is so that when yum updating the user
gets a big clue something is not right. But the danger there is the user
might then not update to kernel-2.6.18-186.el5 as it "conflicts" with
something rather than uninstalling the kmod. Maybe throw in a command
line message for good measure - "this package is deprecated and should
be uninstalled upon the release of el5.5". Maybe it's a less messy solution?

Or I wonder if it is possible to hack a "trigger install" scriptlet into 
kmodtool to overwrite /etc/depmod.d/foo.conf upon install of kernel >= 
2.6.18-186.el5 ?

Something like the following:

cat <<EOF
%triggerin -- kernel >= 2.6.18-186.el5
if [ -e "/etc/depmod.d/foo.conf" ]; then
     cat /dev/null > /etc/depmod.d/foo.conf
fi
EOF

Unfortunately I don't think you could have a package uninstall itself 
from a trigger script as I think that would break the transaction lock 
on the rpm db (one transaction trying to start another transaction).