Re: solving the network-manager-in-gnome problem
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
Reply to: