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

Bug#225465: Suggested course of action to close this bug



On Tue, 30 Dec 2003, Dan Jacobson wrote:
> Debian should no longer be like some mere arcade kiddie game machine,
> where if you don't like the games staring when you deposit your coin,
> then sorry.

It is not anymore.  This has been fixed by invoke-rc.d.  All that remains
now is to give users an easy interface to this machinery.

> surely mess up my system, so I'm not the daring experimenter anymore.

You just have to either:

1. Remove all "S*" links to stuff you don't want stared, OR
2. apt-get install file-rc, and edit the file-rc config file which is
   MUCH easier to use.

You can even use one of the pretty GUI configurator thingies for changing
the links. I don't think there is one for file-rc, but then, file-rc does
NOT need one to be simple to use...

This will *not* stop packages from starting services on their first
install, though.  Any packages that have been fixed to use invoke-rc.d will
not restart the services on package upgrades.  Broken ones still calling
/etc/init.d/whatever directly will, but that's a bug: report it whenever you
find one of these packages.

> Each package that puts a file in /etc/init.d must in its debconf area,
> call [a new debconf element[?]] that will ask the user's wishes as to if
> this package is to be started at boot or not.

There is a much better way.

1. Fix all packages to properly use update-rc.d and invoke-rc.d ONLY, and
   to never run the /etc/init.d file directly  (this is transparent to
   the user).  All maintainers should be changing their packages to use
   invoke-rc.d already, if they invoke initscripts.

2. Write and package a policy-rc.d script that explicitly requires that
   the user has reviewed a package before it can start its services
   (otherwise, the service will be started at package install, even if
   it is not started at boot).   

3. Write a pretty "service manager" thing that:
     1. Manages the rc.d/file-rc service/runlevels stuff
     2. Tells the policy-rc.d in (2) wether services are to be
        active or not on package installs/upgrades.

(1) will be taken care for, but it might take a while untill all packages
    do it.  New packages already do this right.

(2) is very easy to write, and I volunteer to do it.

(3) takes some effort.  Any volunteers?  A good tcl/tk coder can get this
    thing ready in about 4 hours, I think.

THIS solution has the following advantages:

 1.  NO DEBCONF POLUTION OR ANNOYANCES
 2.  It does NOT touch the packages themselves
 3.  It won't face much opposition, since it is non-intrusive, and
     it is also technically sound.
 4.  It doesn't require any policy changes.

> M> Make sure you just delete the start links, not the stop ones. That
> M> should last forever. If you delete all they will be regenerated during
> M> the next update.

This is correct.  Anyone that has read (and paid close attention to) the
update-rc.d manpage (in unstable) knows that.  But it also means you can't
use update-rc.d to do "local administrator" changes to the links (changes
made by update-rc.d ARE lost in the next update), and THAT gets people
confused.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh



Reply to: