On Sun, Jul 22, 2012 at 01:50:58PM +0200, Vincent Lefevre wrote: > On 2012-07-22 11:43:14 +0200, Wouter Verhelst wrote: > > ENABLE/DISABLE switches are *ugly*, > > I disagree. ENABLE/DISABLE switches have some advantages: they are > more readable than a set of symlinks,
That's just an opinion (one which I don't share) > allow all the settings of some service to be grouped in a single > place, No. On the contrary. Services are currently configured in one or two places: - in /etc/rc*.d (whether they run or not) - in the service-specific configuration file (the behaviour of the service) /etc/default is a third place, not a "one and only" place. Using it to specify things like command-line parameters is probably fine. Using it to *override* some other configuration is stupid. > and can be managed more easily by VCS software. At least git supports symlinks just fine. Which VCS system are you using that doesn't? Sounds like you may just need to switch. Additionally, personally I prefer using config management systems for that kind of thing. > > as their effect is not limited to boottime changes. Especially in > > case of packages who ship with such a variable set to disable by > > default, this is very annoying. > > The user may not want a service he didn't request or he hasn't > configured yet to be enabled by default. policy-rc.d is meant to help with that. Disabling stuff through /etc/default doesn't help those users, since they *still* need to use policy-rc.d to disable those services that *don't* come disabled by default. > For instance, some packages may be installed automatically (due to > dependencies), or one may want the client, but not the server. Such > services should be disabled by default. Maybe, but not through a file in /etc/default. It may make sense to make update-rc.d support disabling services by default, a feature which it currently doesn't have, since many people seem to think that'd be a good thing. While I disagree, I can understand the argument. But trying to work around that possible limitation by introducing a whole new layer of inconsistent configuration files which are supported by some initscripts but not by others is just plain silly. I'm seriously considering advocating a release goal for wheezy+1 to get rid of these stupid ENABLE variables. Their only purpose is to annoy people. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120722144048.gq14...@grep.be
