On 2012-07-22 16:40:48 +0200, Wouter Verhelst wrote:
> 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.

No, if the user chooses to deal with /etc/default/<package> file
only (and not with update-rc.d), he will need to look at only
one or two places instead of two or three. And options set in
/etc/default/<package> may already override other configuration,
so that if you want to make things more consistent, you should
get rid of /etc/default entirely.

> > 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.

There are several problems. First the symlinks would need to be copied
to my own working copy. Now I could do that. Then Subversion won't
detect by itself files that have been added or removed. I need to tell
it explicitly, which is annoying, as this isn't done automatically.
But the main problem is the history. If there's only one file, I can
do, e.g. "svn log the_file". But if files (symlinks) are added or
removed, I can no longer get the log. Or I need to do that on the
parent directory, but I would also get the changes concerning the
other services, which is information I don't want.

> Additionally, personally I prefer using config management systems for
> that kind of thing.

I don't think they would do what I want, i.e. track config changes
on the system, either done by me or done automatically (more or less
what diffmon does, but diffmon cannot handle the rc*.d symlinks).

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120723021906.GB7408@ypig.lip.ens-lyon.fr">http://lists.debian.org/20120723021906.GB7408@ypig.lip.ens-lyon.fr

]] Vincent Lefevre

> OK, if Debian plans to support other init systems, that's fine.

It already does.

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87hasy6g7j.fsf@vuizook.err.no">http://lists.debian.org/87hasy6g7j.fsf@vuizook.err.no

Le mercredi, 18 juillet 2012 13.04:36, Wookey a écrit :
> I don't use n-m because it doesn't play nice with usb0 gadget
> networking.

I have read this claim multiple times now and it got me confused: on a wheezy
laptop with network-manager and KDE, I can connect my Android phone trough USB
and get internet access trough it just fine; it just worksâ„¢.

Where's the issue ? When this USB connection shouldn't be used as "the uplink
connection" ?

Cheers,

OdyX


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201207231219.26605.odyx@debian.org">http://lists.debian.org/201207231219.26605.odyx@debian.org

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.

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.

> to my own working copy. Now I could do that. Then Subversion won't
> detect by itself files that have been added or removed. I need to tell
> it explicitly, which is annoying, as this isn't done automatically.
> But the main problem is the history. If there's only one file, I can
> do, e.g. "svn log the_file". But if files (symlinks) are added or
> removed, I can no longer get the log. Or I need to do that on the

Use the right tool for the job. SVN is crap for this particular use case,
and any difficulties involving the use of svn to track /etc are irrelevant
because it simply cannot be expected to work properly anyway. Switch to
etckeeper + git or something else that can version-control symlinks, owner
and mode changes in an useful way (git itself is not enough, thus the use of
etckeeper on top of git).

And that has nothing to do with the interesting part, which is to remove
enable/disable switches for initscripts from /etc/default.

--
"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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120723102340.GA9103@khazad-dum.debian.net">http://lists.debian.org/20120723102340.GA9103@khazad-dum.debian.net

On 2012-07-23 10:21:04 +0200, Tollef Fog Heen wrote:
> ]] Vincent Lefevre
>
> > OK, if Debian plans to support other init systems, that's fine.
>
> It already does.

Not really, or at least not in a nice way, because sysvinit is
an essential package. Also, I don't see any init system that
provides the same feature as ENABLE/DISABLE (i.e. together with
other configuration options of the service, such as the port on
which the daemon will listen).

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120723131006.GB9743@ypig.lip.ens-lyon.fr">http://lists.debian.org/20120723131006.GB9743@ypig.lip.ens-lyon.fr

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.

> 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.

> > to my own working copy. Now I could do that. Then Subversion won't
> > detect by itself files that have been added or removed. I need to tell
> > it explicitly, which is annoying, as this isn't done automatically.
> > But the main problem is the history. If there's only one file, I can
> > do, e.g. "svn log the_file". But if files (symlinks) are added or
> > removed, I can no longer get the log. Or I need to do that on the
>
> Use the right tool for the job. SVN is crap for this particular use case,
> and any difficulties involving the use of svn to track /etc are irrelevant
> because it simply cannot be expected to work properly anyway. Switch to
> etckeeper + git or something else that can version-control symlinks, owner
> and mode changes in an useful way (git itself is not enough, thus the use of
> etckeeper on top of git).

etckeeper is not the right tool because it will store private data
(e.g. passwords and private keys). I want to track only public data
and only files for which I have done a local modification.

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120723132629.GC9743@ypig.lip.ens-lyon.fr">http://lists.debian.org/20120723132629.GC9743@ypig.lip.ens-lyon.fr

On 2012-07-23 15:26:29 +0200, Vincent Lefevre wrote:
> 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.

And something else that can be done via /etc/default is that one
can write comments (e.g. "Temporarily disabled because of bug..."),
something that cannot be done with "update-rc.d".

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120723133633.GA11555@ypig.lip.ens-lyon.fr">http://lists.debian.org/20120723133633.GA11555@ypig.lip.ens-lyon.fr

]] Vincent Lefevre

> On 2012-07-23 10:21:04 +0200, Tollef Fog Heen wrote:
> > ]] Vincent Lefevre
> >
> > > OK, if Debian plans to support other init systems, that's fine.
> >
> > It already does.
>
> Not really, or at least not in a nice way, because sysvinit is
> an essential package.

How is that relevant? Don't we support pax just because tar is
essential?

> Also, I don't see any init system that provides the same feature as
> ENABLE/DISABLE (i.e. together with other configuration options of the
> service, such as the port on which the daemon will listen).

You might want to look again, then, there are multiple ways to disable a
daemon using systemd units.

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 874noyfupc.fsf@xoog.err.no">http://lists.debian.org/874noyfupc.fsf@xoog.err.no

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120723165920.GM25141@codelibre.net">http://lists.debian.org/20120723165920.GM25141@codelibre.net

On 2012-07-23 15:55:27 +0200, Tollef Fog Heen wrote:
> ]] Vincent Lefevre
>
> > On 2012-07-23 10:21:04 +0200, Tollef Fog Heen wrote:
> > > ]] Vincent Lefevre
> > >
> > > > OK, if Debian plans to support other init systems, that's fine.
> > >
> > > It already does.
> >
> > Not really, or at least not in a nice way, because sysvinit is
> > an essential package.
>
> How is that relevant? Don't we support pax just because tar is
> essential?

But installing pax won't remove tar, while...

# apt-get install -s upstart
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
libnih-dbus1 libnih1
The following packages will be REMOVED:
sysvinit
The following NEW packages will be installed:
libnih-dbus1 libnih1 upstart
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
sysvinit
0 upgraded, 3 newly installed, 1 to remove and 17 not upgraded.
Remv sysvinit [2.88dsf-28]
[...]

> > Also, I don't see any init system that provides the same feature as
> > ENABLE/DISABLE (i.e. together with other configuration options of the
> > service, such as the port on which the daemon will listen).
>
> You might want to look again, then, there are multiple ways to disable a
> daemon using systemd units.

OK, the package description of systemd by mentioning the rcN.d links.
I had the impression they were still used.

Also, it seems that to disable a daemon using systemd units, one needs
these native files. But many packages don't provide them. So, real
systemd support isn't really there.

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120723222818.GA8809@ypig.lip.ens-lyon.fr">http://lists.debian.org/20120723222818.GA8809@ypig.lip.ens-lyon.fr