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

Re: solving the network-manager-in-gnome problem



On Mon, Jul 23, 2012 at 03:26:29PM +0200, Vincent Lefevre wrote:
> On 2012-07-23 07:23:40 -0300, Henrique de Moraes Holschuh wrote:
> > On Mon, 23 Jul 2012, Vincent Lefevre wrote:
> > > so that if you want to make things more consistent, you should
> > > get rid of /etc/default entirely.
> > 
> > /etc/default is used for a lot more than just enabling/disabling services,
> > and it will not go away.
> 
> But with /etc/default, you can override options. For instance,
> for sshd, the port can be provided either in /etc/ssh/sshd_config
> or in /etc/default/ssh.

One one and only purpose of a file in /etc/default is to modify
the behaviour of the init script, as an alternative to editing
the script directly (since this causes dpkg conffile prompts and
is quite annoying).

The fact that sshd lets you add additional arbitrary options there
does not make that the intended use or good practice.  It is
neither.

> > Now, if you just mean removing enable/disable switches for initscripts from
> > /etc/default/*, that should be doable with some effort.  And that's what
> > this subthread is about.
> 
> No, I just mean that configuration of some service should be
> in a limited number of places. But if you agree that it's fine
> for /etc/default to override config setup somewhere else, then
> there should not be any problem with ENABLE/DISABLE.

It's not compatible with init systems which do not use the init
scripts directly, e.g. systemd.  A common interface for enabling/
disabling is required, which can then do the system-specific
thing for enabling/disabling.  That should probably be
update-rc.d (though the name is sysvinit-specific).  Since we're
going to be changing the update-rc.d interface in wheezy+1,
maybe we could simply replace it with e.g. update-service and
provide a compatibility wrapper.  And we should ensure that all
init systems provide add/remove/enable/disable actions.  The
stop|start actions are going to simply defer to the "defaults"
action, and will ultimately go.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


Reply to: