[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Release update

Le mar 30/03/2004 à 16:23, Joachim Breitner a écrit :
> Hi,
> This would require some clarifications (is update-rc.d now for
> administrators or for package maintainers)

Considering all I read here about update-rc.d, I'd say that it was
(at least) designed to be used by package maintainers. As explained
it's hard to use it correctly if you're not aware of some package
maintainance subtilities (the last link in /etc/rc?.d/ for example),
which is not even described in the man page.

But, when someone ask where is chkconfig (the RH version of
update-rc.d), everybody reply that it's update-rc.d.
So from this PoV, I consider that it's also an administrator tool.

And there's still the "good ol' days" way:
find /etc/rc?.d/ -name "???service" -exec rm {} \;

>  and some common guidelines
> (some packages currently use /etc/defaults/something, some use the
> symlinks in /etc/rc?.d directly, others have something set in
> /etc/init.d/something or use some magic, like checking for a line in
> /etc/inetd.conf).
> Ideally, all network daemons, from the administrator POV:
>  * are installed disabled
>  * may be started temporarily (/etc/init.d/package start)
>    - then being logrotated, restarted on upgrade, but no start on boot
>  * may be started permanently (perhaps symlinking in /etc/rc?.d)
>    - logrotated, restarted on upgrade, restarted on boot
>  * may then be temporarily disabled (/etc/init.d/package stop)
>    - no logrotate restart, no start on upgrade, but start on boot.


> Questions to be solved: how to implement, what interface for package
> maintainers, what interface for administrators

In a pleasant world update-rc.d should be enough for both.
The main problem seems to be that the design of update-rc.d is

Quoted from Henning Makholm:

> > What is the reason for this behaviour?
> It is easy to implement in update-rc.d without needing specific
> support from the maintainer scripts to tell it whether the
> package is being installed anew or just updated (or resurrected from
> removed-but-not-purged state).

As I understand this (correct me if I'm wrong), when update-rc.d
is called (.postinst ?) by a package, it is unable to know if it's
performing an install (create the links) or an update (don't touch
So, update-rc.d is based on a hack, which check if there is at least
a single link remaining in /etc/rc?.d/ to guess if the package is
already installed or not.

There are several drawbacks in this situation:
 - there are (heavy) chances that update-rc.d asumptions are false.
If the admin want to disable a service, he will make a find/rm, or
read the update-rc.d man page and make update-rc.d -f.
update-rc.d behaviour will then be wrong, performing an install
instead of an update, and violating the policy about /etc files.

 - As it's based on hack, an admin needs to know about this
to use update-rc.d correctly. ie: the admin needs to perfrom a
hack to make a simple task.

So, I guess that the real question to ask is more:
How (or when) can we know during the package installation if we're
performing an install or an update, to call update-rc.d accordingly?

With this, you can remove the hack from update-rc.d, and it can be 
used by both package managers and administrators.
This is mainly a package update problem.


Reply to: