Andrew Stribblehill <a.d.stribblehill@durham.ac.uk> [2002-11-08 15:49:27 +0000]: > I can see a number of ways out of it, but have no clear idea which is > best: > > * Split the package into its component parts, such that each daemon > is in a separate package. Have an init script for each. The admin > chooses which daemons run by adding and removing packages. This seems simple for the end user of the system. It seems hard to think of ways to complicate it. Note that a previous thread had a discussion of this of daemon start up scripts. You might want to browse the thread, I suggest starting here. Although you are probably already well versed there. http://lists.debian.org/debian-devel/2002/debian-devel-200209/msg01791.html > * Put a debconf message into the package warning that the behaviour > has changed. Write one init script. Allow the user to configure > which daemons start at boot-time by editing /etc/default/cfengine2 > which contains RUN_CFEXECD=0; RUN_CFENVD=1; ... May I voice an opinion against a gratuitous message saying that the behavior has changed but without real useful value? Those darn "click-throughs" are a large part of the complaints against debian packages during an install. May I suggest that if at all possible avoid needing user input during the installation. Especially for a program such as cfengine which gains usefulness on larger sites with many hosts. Trying to install something with a "press enter to continue" on a thousand hosts such as a large cfengine user might need to do would be extremely tedious. If at all possible please allow the package to be installed non-interactively. > * As above, but manage /etc/default/cfengine2 by debconf. If I do > this, must this file not be a conffile? As a system user when I have had to tinker with files in /etc/default I have always hated not having a backup of the file. If I break it how can I restore it to a package default? apt-get --purge remove and then install? Yuck! Even apt-get --reinstall install is not the most pleasant way to deal with this since then AIDE/Tripwire alarms will be triggered for the non-configuration files changed. May I suggest keeping a clean copy of any file that the user might modify in /usr/share/doc beside the package documentation? That way I can always diff between my local customizations and the package version and it gives me an easy way to see what I have changed. > * Write three init scripts and keep them in the same single package. > Has this got a precedent? This seems functionally to be no different than your suggestion to have one init script which decides which of the three to start. But it suffers from being more complicated. Just my two cents... Bob
Attachment:
pgpCvT_t9vdf5.pgp
Description: PGP signature