[elrepo-devel] Deprecating packages
Phil Perry
phil at elrepo.org
Sat Mar 6 20:35:47 EST 2010
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).
More information about the elrepo-devel
mailing list