Bug#225465: debian-policy: packages must give choice to not start at boot, via debconf
Package: debian-policy
Version: 3.6.1.0
Severity: wishlist
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.
> So many packages, so few that I need started at every boot.
>
> So I file wishlist bugs "please add a debconf item to not start at boot".
>
> Do various things that change the links in /etc/rc.*, I was told. Uh
> huh, lasted until the next upgrade of that package.
W> No, that shouldn't be true. Check your findings; if you find a package
W> which indeed shows this behaviour please file a bug with severity
W> "serious". Whether or not a package starts at boot is local
W> configuration, and retaining local configuration is a "must" directive
W> in Debian Policy.
I see "update-rc.d -f fetchmail remove" in my bash history list, but
perhaps this is just like the other poster said, removing more links
than proper, thus getting into trouble later at upgrade.
Anyway, I'd rather not poke further, as one little error and I'll
surely mess up my system, so I'm not the daring experimenter anymore.
And what if successful, and then the machine gets transfered to a
different maintainer, or the same maintainer after his memory has
faded. Then it will take a long time to figure out why a package
isn't working as expected --- apparently some links are missing, they
discover.
And the frailty of the instructions on link dismemberment, which have
to be garnered from asking in newsgroups... how is the user to
remember the proper way to revisit the situation in several months to
make adjustments if needed? Wouldn't a comfy debconf dialog be better
than having to try to remember what one changed, and what newsgroups
one asked what questions to try and 'kluge forthward' further, in
meddling with the links in way that each differing package maintainer
never expected, though "legal".
How about something like [you guys improve it please]:
Policy suggestion for packages that might start at boot, /etc/init.d/*:
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.
For those packages that are so essential that it wouldn't make sense
to not start them at boot, stern warnings should be placed not to
chose to not start... note in every case we still force the maintainer
to deal with users who don't want the package starting at boot... this
is better than hoping one day they will deal with the issue.
This way, developers and users will have a common bridge to the land
of not starting a package at boot. Users will not have to something
the developer didn't anticipate, etc. etc.
Anyway, debian needs a way, guaranteed to be available from
dpkg-reconfigure, to stop packages from starting at boot.
Note that some packages should make this a multi choice:
start at boot, boot and ppp, ppp only, none. etc.
hmm, another recent wishlist of mine:
> I only want to use ircd-hybrid once a month, but reboot every day.
> Therefore a debconf item should be made that prevents starting at boot.
J> This is a very user-specific kind of request, and due to the obviously
J> global audience this package has, I can't do this.
J> For you, just rm /etc/rc*.d/*ircd-hybrid and that should do the trick..
Maybe not, as another poster pointed out one shouldn't rm all the
links, lest the get rebuilt at upgrade, and also, stopping at shutdown
is still nice when we started by hand.
Plus, I'll never remember what I did, plus a user like me has no
business issuing commands like rm /etc/anything, much less posting in
this devel group.
Hylafax is neat, but I only fax rarely.
fetchmail is neat, but if I haven't connected yet, doesn't make sense.
exim4 too.
apache? only during experiments [good thing he has implemented not
starting at boot]
cups? one day I will get that printer fixed.
hotplug? only when I rarely take photos
etc. etc.
"Well, just remove the package until you are ready to use it": but
then one loses out in apt-get dist-upgrade, worse with just CDs,
apt-zip, and modem too.
Anyway, debconf is the natural central point for dealing with whether
to start at boot or not, the only place we users will remember, and
the right place for developers to implement what ought to be done for
their particular package... one shouldn't just assume that not running
their boot scripts is the right way in every case.
Ah, here is what Michael Meskes said:
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.
i.e. even top developers aren't as clear as Michael as to what must
not be done, not even to mention users. So word of mouth unofficial
ways are bad. There should be an official standard way, and it
belongs in debconf. If link tampering is the official standard way,
then making it doable from debconf should be no big deal. If it
cannot be found inside debconf for a particular package, then that
means it isn't standard... maybe even a dpkg-reconfigure
--dont-start-at-boot, dpkg-reconfigure --start-at-boot could be
available, but note there are some 3, 4 way cases, like fetchmail,
exim, where ppp complicates the choices.
Reply to: