Description of problem:
After an update of cups it starts on boot, even when the previous
version was set to not start on boot. So if cups is installed, but not
in use, a user who thinks they have it disabled will have it
re-enabled at boot when they upgrade. This may leave them open to
future cups holes (god forbid) when they think the service is off...
Version-Release number of selected component (if applicable):
cups-1.1.22-0.rc1.8.4 and earlier
Get an older version of cups, turn it off on boot, upgrade.
Steps to Reproduce:
rpm -U --oldpackage cups-1.1.22-0.rc1.8.3.i386.rpm \
chkconfig --del cups
rpm -U cups-1.1.22-0.rc1.8.4.i386.rpm \
chkconfig --list | grep cups [shows cups on]
Cups is set to start on boot.
Cups is left at it's previous setting to not start on reboot. Apache,
for example, honors it's previous setting.
I don't quite get why this is happening, but I checked out the
differences between cups & httpd.
Snippets from their specs:
/sbin/chkconfig --add cups || true
/sbin/chkconfig --add httpd
I don't get why they have different behaviour...
Also, it appears in bugzilla there is an entry for "cup" as well (note
Thanks. This has been fixed in CVS.
(The "cup" bugzilla component is for the "cup" package.)
Ok. I'm being lazy here as I know I should open separate tickets, but
it's late... These packages have a similar problem:
I'm putting it here so it doesn't get lost before I forget. ;)
Also, what was the voodoo to fix it? It would be handy for us lesser
geeks to know how it was fixed in the ticket.
Thanks for the quick fix!
Apparently, `chkconfig off` should be used instead of `--del`, so this
is actually NOTABUG (?). Per pcmcia resolution by davej.
It's not to do with that at all, but caused by the initscript not
being marked noreplace.
Hmm. Ok, then are the others bugs or not? I closed 'em as NOTABUG
after the pcmcia-cs maintainer (davej) said it wasn't a bug. I can
re-open those, leave closed, or forget. ;)
Also, should /etc/rc.d/init.d/cups really be marked noreplace? I mean,
what if there are improvements/fixes to it in future releases?
I think davej may actually be right `man chckonfig`:
The service is removed from chkconfig management, and any sym-
bolic links in /etc/rc[0-6].d which pertain to it are removed.
Note that future package installs for this service may run chk-
config --add, which will re-add such links. To disable a ser-
vice, run chkconfig name off.
Sorry if I'm being noisy...
Yes, it should be noreplace.
Dave said that *you* shouldn't use chkconfig --del, and he's right. The RPM
scriptlet *should* use it, however, since it runs after the package is removed.