Bug 170567

+++ This bug was initially created as a clone of Bug #169623 +++

Description of problem:
kbd-1.08-10.1 includes the keytable service, but kbd-1.0.8-11 doesn't so a
%triggerun was added to remove the keytable service upon removal of kbd < 1.08-11:

triggerun scriptlet (using /bin/sh) -- kbd < 1.08-11
/sbin/chkconfig --del keytable

The problem is that we then built kbd-1.08-10.2 which doesn't include the
keytable service and is currently the RHEL3 shipping version of kbd (and
includes the above %triggerun)  Net result is that when upgrading from RHEL3 ->
RHEL4 the trigger fires and we get the following error:

Upgrading kbd-1.12-2.x86_64.
error reading information on service keytable: No such file or directory
error: %trigger(kbd-1.08-10.2.x86_64) scriptlet failed, exit status 1

Should probably think about releasing a new kbd version where the trigger is
modified to be:

triggerun scriptlet (using /bin/sh) -- kbd < 1.08-10.2
/sbin/chkconfig --del keytable

Version-Release number of selected component (if applicable):

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

-- Additional comment from mitr on 2005-09-30 09:11 EST --
This is #144434, already fixed in rawhide.  kbd-1.08-10.2 contains the same
trigger, so it would trigger on _itself_.  AFAICS there's no way to fix that
except asking the user to rpm -e --notriggers kbd.
 


-- Additional comment from jturner on 2005-09-30 12:25 EST --
Correct, there is on way to fix -10.2 but figured it might be worthwhile to
release an updated version of the kbd package for RHEL-3 which didn't have the
trigger.  That would help prevent problems when using anaconda to update to RHEL4.

-- Additional comment from mitr on 2005-09-30 12:39 EST --
(Bug 144434, comment 12 says even an upgrade wouldn't get rid of the trigger.
I don't quite believe that, but if it is so, we could only fix updates from the
new version, that never had -10.2.)

But yes, we can fix at least upgrades from fixed RHEL3 to fixed RHEL4 (the same
change is missing in RHEL4).


-- Additional comment from laroche on 2005-10-04 06:51 EST --
Triggers are not kept forever, so releasing a fixed package should also
fix this update problem.

greetings,

Florian La Roche


-- Additional comment from jturner on 2005-10-04 08:25 EST --
Yeah, my intent was to get a package with the correct trigger released so that
folks that updated from the new RHEL3 package to RHEL4 wouldn't hit the "bad"
trigger.