Re: RFC: OpenRC as Init System for Debian

[Gergely Nagy]

Josselin Mouette  writes:

> Le dimanche 13 mai 2012 à 20:00 +0200, Gergely Nagy a écrit : 
>> > There is a huge difference between gconf, for which you can set one
>> > specific setting in /etc, overriding the default in /usr (and in a way
>> > that will not break the application if the schemas change), and
>> > systemd/udev, which require to copy the *entire* file, leaving behind
>> > any improvements that could made to it in ulterior versions.
>> 
>> Not entirely true. You can override parts of the file too, without
>> copying: include the original. This doesn't let you override everything,
>> but for a lot of things, is good enough.
>
> And then, when the original file changes, you lose the improvements and
> you might even end up with a broken system.
>
> For example if a systemd unit file is updated to match a change of
> behavior in a daemon. Say, from now it requires a pre-exec stanza to do
> stuff it used to do at startup. Your modified file in /etc will not
> include this new stanza and your daemon is broken.

Same problem exists with conf.d/ snippets. It's nothing unique to
systemd, nor to etc-overrides-lib.

If you can override, include or otherwise configure your system in such
a way that you do not get warned when one part changes incompatibly, it
will likely break, indeed.

That is what NEWS.Debian can be used for, for example. But in systemd's
case, there are better options, as discussed in this thread elsewhere
(and from what I've been told, with a little bit of postinst magic, this
can easily become a non-issue, but I haven't tested that yet).

-- 
|8]


--
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/87ipfwphgs.fsf@algernon.balabit

Re: RFC: OpenRC as Init System for Debian

[Tollef Fog Heen]

]] Stefan Fritsch 

> For example, the apache2 init script starts htcacheclean if and only 
> if mod_disk_cache is enabled. While this could arguably be considered 
> as an upstrem deficiency, such cases won't simply disappear because 
> systemd becomes more common.

Ideally, they will, but even if they dont…

> And fixing this in the daemon as part of a packager's work is not
> feasible.

ExecStartPre=some_script_that_checks_if_htcacheclean_is_needed_and_starts_it


[...]

> Also, the apache2 init script creates various required directories on 
> volatile file systems like /var/run or /var/lock and supports multiple 
> running instances, but these are more common problems.

tmpfiles.d for the directories, multiple instance support is built-in
already, so that becomes easier if anything.

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


--
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/87wr4c8w1t@qurzaw.varnish-software.com

Re: RFC: OpenRC as Init System for Debian

[Fernando Lemos]

On Tue, May 15, 2012 at 5:38 PM, Stefan Fritsch  wrote:
> On Wednesday 09 May 2012, Gergely Nagy wrote:
>> > Apart from the fact that requirements will be different on
>> > different systems. Putting functionality for all possible corner
>> > cases into the daemon is not sensible for any upstream.
>>
>> That is what configuration files and similar things are for, I
>> believe.
>>
>> I'd love to see an example where a complex init script is needed,
>> and that can't be easily turned into systemd service files (for
>> example). So far, I was told of two cases where the init script
>> does more than a simple unit file does: one was nbd-client, which
>> does funky stuff I dared not try to understand last night, the
>> other is every package that supports starting multiple instances
>> of the same service.
>
> For example, the apache2 init script starts htcacheclean if and only
> if mod_disk_cache is enabled. While this could arguably be considered
> as an upstrem deficiency, such cases won't simply disappear because
> systemd becomes more common. And fixing this in the daemon as part of
> a packager's work is not feasible. And with my upstream hat on, I
> would rather spend my time on fixing real bugs than things that can be
> easily worked around by the init script (or the apachectl script).
>
> Also, the apache2 init script creates various required directories on
> volatile file systems like /var/run or /var/lock

Move this logic out of the init script and use ExecStartPre? That way
the same logic can be used by all init systems.

Please read systemd.service(5) if you haven't already.

> and supports multiple
> running instances, but these are more common problems.

As far as I can tell, systemd supports multiple instances natively...

Regards,


-- 
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/canvyna-oiacd2jvveuphlpvuqhsxzzv-jaosjnkqkxk7ldy...@mail.gmail.com

Re: RFC: OpenRC as Init System for Debian

[Stefan Fritsch]

On Wednesday 09 May 2012, Gergely Nagy wrote:
> > Apart from the fact that requirements will be different on
> > different systems. Putting functionality for all possible corner
> > cases into the daemon is not sensible for any upstream.
> 
> That is what configuration files and similar things are for, I
> believe.
> 
> I'd love to see an example where a complex init script is needed,
> and that can't be easily turned into systemd service files (for
> example). So far, I was told of two cases where the init script
> does more than a simple unit file does: one was nbd-client, which
> does funky stuff I dared not try to understand last night, the
> other is every package that supports starting multiple instances
> of the same service.

For example, the apache2 init script starts htcacheclean if and only 
if mod_disk_cache is enabled. While this could arguably be considered 
as an upstrem deficiency, such cases won't simply disappear because 
systemd becomes more common. And fixing this in the daemon as part of 
a packager's work is not feasible. And with my upstream hat on, I 
would rather spend my time on fixing real bugs than things that can be 
easily worked around by the init script (or the apachectl script).

Also, the apache2 init script creates various required directories on 
volatile file systems like /var/run or /var/lock and supports multiple 
running instances, but these are more common problems.


> The latter isn't hard to convert to systemd, and will even be
> simpler, as far as I see.
> 
> > And the integrator/packager may not want to learn all the funny
> > languages that daemons can be written in (ocaml, haskell, java,
> > ruby, ...). Besides, init scripts are conf files on Debian for
> > good reasons.
> 
> So are unit files and configuration files. If the daemon can't be
> configured and started properly without an init script's help, then
> something's very broken.
> 
> Exceptions do exist, of course, but that falls under the
> 'absolutely necessary' label.
> 
> I'd love to hear about examples though. If for nothing else, than
> to try my hands at making them work with systemd, it sounds like
> an amusing challenge.


-- 
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/201205152238.40909...@sfritsch.de

Re: RFC: OpenRC as Init System for Debian

[David Weinehall]

On Tue, May 15, 2012 at 05:26:32PM +0200, Josselin Mouette wrote:
> Le dimanche 13 mai 2012 à 20:00 +0200, Gergely Nagy a écrit : 
> > > There is a huge difference between gconf, for which you can set one
> > > specific setting in /etc, overriding the default in /usr (and in a way
> > > that will not break the application if the schemas change), and
> > > systemd/udev, which require to copy the *entire* file, leaving behind
> > > any improvements that could made to it in ulterior versions.
> > 
> > Not entirely true. You can override parts of the file too, without
> > copying: include the original. This doesn't let you override everything,
> > but for a lot of things, is good enough.
> 
> And then, when the original file changes, you lose the improvements and
> you might even end up with a broken system.
> 
> For example if a systemd unit file is updated to match a change of
> behavior in a daemon. Say, from now it requires a pre-exec stanza to do
> stuff it used to do at startup. Your modified file in /etc will not
> include this new stanza and your daemon is broken.
> 
> (And yes, this could be handled easily with a modified ucf, but
> currently it is not the case.)

Uhm, I think there's a misunderstanding here somewhere (or I'm
misunderstanding your objection).

The file in /etc *includes* the file in /lib.  You don't copy them.

The file in /lib is the unit file that gets updated, the file in /etc only
contains overrides for the values you want to override.

Thus, when /lib changes, those updates will be included, no breakage.

The only issue I can think of is that there's currently (TTBOMK) no way
of unsetting a value completely, which can cause issues if you want to
override a setting that can take multiple statements.


Regards: David
-- 
 /) David Weinehall  /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
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/20120515163916.gh10...@suiko.acc.umu.se

Re: RFC: OpenRC as Init System for Debian

[Stephan Seitz]

On Tue, May 15, 2012 at 05:26:32PM +0200, Josselin Mouette wrote:

Le dimanche 13 mai 2012 à 20:00 +0200, Gergely Nagy a écrit :

Not entirely true. You can override parts of the file too, without
copying: include the original. This doesn't let you override everything,
but for a lot of things, is good enough.

And then, when the original file changes, you lose the improvements and
you might even end up with a broken system.

For example if a systemd unit file is updated to match a change of
behavior in a daemon. Say, from now it requires a pre-exec stanza to do
stuff it used to do at startup. Your modified file in /etc will not
include this new stanza and your daemon is broken.


Now I am confused. I thought this was the advantage of the include 
function of systemd. So, your etc-configuration file has as first line 
„:include lib-configuration file” and then your modifications.


If a unit file is updated in /lib, you have the new stanza thanks to your 
include function.


Of course this can still break the daemon, because your own changes 
couldn’t be valid anymore.



The problem is that we seem to have three cases:

- default configuration file is in /lib; if the daemon detects a file in 
  /etc, it will read the file in /lib and then in /etc and merge the 
  files together (which application does this?)
- default configuration file is in /lib; if the daemon detects a file in 
  /etc, it will only read the etc-file; thanks to the include support you 
  can include the lib-file in the etc-file and only add the stanza you 
  need (e.g. systemd)
- default configuration file is in /lib; if the daemon detects a file in 
  /etc, it will only read the etc-file; without include function you have 
  to copy the complete lib-file to etc and edit it (e.g. udev)


I don’t think we can force one of the cases as rule via policy, so the 
etc-directory should contain a README (e.g. in /etc/udev/rules.d) 
explaining how to change the default configuration.


Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: RFC: OpenRC as Init System for Debian

[Josselin Mouette]

Le dimanche 13 mai 2012 à 20:00 +0200, Gergely Nagy a écrit : 
> > There is a huge difference between gconf, for which you can set one
> > specific setting in /etc, overriding the default in /usr (and in a way
> > that will not break the application if the schemas change), and
> > systemd/udev, which require to copy the *entire* file, leaving behind
> > any improvements that could made to it in ulterior versions.
> 
> Not entirely true. You can override parts of the file too, without
> copying: include the original. This doesn't let you override everything,
> but for a lot of things, is good enough.

And then, when the original file changes, you lose the improvements and
you might even end up with a broken system.

For example if a systemd unit file is updated to match a change of
behavior in a daemon. Say, from now it requires a pre-exec stanza to do
stuff it used to do at startup. Your modified file in /etc will not
include this new stanza and your daemon is broken.

(And yes, this could be handled easily with a modified ucf, but
currently it is not the case.)

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
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/1337095592.3589.290.camel@pi0307572

Re: Configuration file handling (was: RFC: OpenRC as Init System for Debian)

[Steve Langasek]

On Fri, May 11, 2012 at 01:41:32PM +0100, Roger Leigh wrote:
> On a related note...
> While we might criticise rpm for its bad conffile handling, dpkg is
> itself fairly woeful, and if we change one thing for wheezy+1, it
> should be sane conffile handling.  dpkg should never "forget" about
> conffiles; the fact that maintainer scripts have to take care of
> purging such files is a glaring defect, and possibly the source of
> the greatest fragility in our maintainer scripts--it's impossible for
> maintainer scripts to get this right all the time given all the
> corner cases like downgrades and being taken over by other packages.
> If this was implemented robustly, the maintainer script should never
> need to concern itself with such cleanup, or indeed any manual work
> with conffiles at all, except maybe for deletion ahead of purge
> where this is needed.  And given the frequency this is needed, a
> defined mechanism to do this would be useful.

Since maintainer scripts have nothing to do with purging conffiles on
package purge, I guess you're talking here about packages failing to clean
up on upgrade when a new version of the package no longer ships a conffile
that was present in the old version.

The flaw in your argument is that whereas it's difficult for maintainer
scripts to always do the right thing, it's *impossible* for dpkg to always
do the right thing without more information from the package itself.  You
cannot assume that removing the conffile from the filesystem is the right
thing to do on package upgrade; for instance, it may have been changed from
conffile to non-conffile config file, in which case removing the conffile
will obliterate the user's settings that the package maintainer expected
would be retained.

dpkg's conffile handling continues to become /increasingly/ robust and
provide improved interfaces for package maintainers -
dpkg-maintscript-helper being the latest long-sought addition.  At this
point the primary causes of mis-handling of configuration files is
maintainers that have failed to read or understand policy.  I don't think
there's much more automation to be squeezed out of dpkg to cover for such
lackluster maintainer education.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: RFC: OpenRC as Init System for Debian

[Gergely Nagy]

Josselin Mouette  writes:

> Le vendredi 11 mai 2012 à 11:25 +0200, Gergely Nagy a écrit :
>> Thomas Goirand  writes:
>> > The fact that these files are in /lib and shouldn't be touched by the admin
>> > doesn't make them less configuration files. They still match the above
>> > definition from Wikipedia.
>> 
>> Can I point you to /usr/share/glib-2.0/schemas/,
>> /usr/share/gconf/defaults and similar?
>> 
>> These are by the above definition, configuration files. Yet they are not
>> under /etc. They are used to load the initial configuration of software,
>> and can be overridden elsewhere (funny thing is, the gconf defaults can
>> be overridden with stuff in /var/lib/gconf/debian.* - even the overides
>> are outside of /etc!).
>
> Utterly wrong. The stuff in /var/lib/gconf is autogenerated, and any
> changes you do in it will not be preserved.
> The system administrator’s overrides have to be put in /etc/gconf.

Please read the "by the above definition" part. I know very well these
are not configuration files, the same way /lib/systemd/system/ stuff
isn't, either.

I'm glad it can be overridden in /etc too, but that wasn't the point.

>> Can we fix these first, where not even the overrides are in /etc, let
>> alone the defaults? Please?
>
> Can we get rid of useless babbling on debian-devel? Please?

Perhaps if you'd read what I was replying to, you would have noticed
what I was attempting to do: show that how silly the configuration file
definition quoted before was.

>> And in etc-overrides-lib, config files still remain in /etc. Its just
>> the defaults that live elsewhere. That the defaults are files, and are
>> under /lib, is an implementation detail, similarly how gconf defaults
>> live under /usr/share/gconf/defaults.
>
> There is a huge difference between gconf, for which you can set one
> specific setting in /etc, overriding the default in /usr (and in a way
> that will not break the application if the schemas change), and
> systemd/udev, which require to copy the *entire* file, leaving behind
> any improvements that could made to it in ulterior versions.

Not entirely true. You can override parts of the file too, without
copying: include the original. This doesn't let you override everything,
but for a lot of things, is good enough.

For the rest, well, it's a bit of inconvenience, but nothing that can't
be fixed with a clever script to warn about the original files changing.

-- 
|8]


--
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/87y5ow3qs5@luthien.mhp

Re: RFC: OpenRC as Init System for Debian

[Josselin Mouette]

Le vendredi 11 mai 2012 à 11:25 +0200, Gergely Nagy a écrit :
> Thomas Goirand  writes:
> > The fact that these files are in /lib and shouldn't be touched by the admin
> > doesn't make them less configuration files. They still match the above
> > definition from Wikipedia.
> 
> Can I point you to /usr/share/glib-2.0/schemas/,
> /usr/share/gconf/defaults and similar?
> 
> These are by the above definition, configuration files. Yet they are not
> under /etc. They are used to load the initial configuration of software,
> and can be overridden elsewhere (funny thing is, the gconf defaults can
> be overridden with stuff in /var/lib/gconf/debian.* - even the overides
> are outside of /etc!).

Utterly wrong. The stuff in /var/lib/gconf is autogenerated, and any
changes you do in it will not be preserved.
The system administrator’s overrides have to be put in /etc/gconf.

> Can we fix these first, where not even the overrides are in /etc, let
> alone the defaults? Please?

Can we get rid of useless babbling on debian-devel? Please?

> And in etc-overrides-lib, config files still remain in /etc. Its just
> the defaults that live elsewhere. That the defaults are files, and are
> under /lib, is an implementation detail, similarly how gconf defaults
> live under /usr/share/gconf/defaults.

There is a huge difference between gconf, for which you can set one
specific setting in /etc, overriding the default in /usr (and in a way
that will not break the application if the schemas change), and
systemd/udev, which require to copy the *entire* file, leaving behind
any improvements that could made to it in ulterior versions.

-- 
.''`.  Josselin Mouette
: :' :
`. `'
  `-


--
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/1336928648.2522.8.camel@tomoe

Re: RFC: OpenRC as Init System for Debian

[Josselin Mouette]

Le vendredi 11 mai 2012 à 11:37 +0200, Tollef Fog Heen a écrit :
> I have /lib/systemd/system/foo.service and want to change something in
> it, I then create /etc/systemd/system/foo.service with a copy of the
> /lib one plus whatever changes I want.
> 
> The version in /lib is then updated.  How is the admin notified?

The postinst script could run ucf but only if the file in /etc exists.
It doesn’t seem very complicated to implement with existing tools.
(Alternatively this could be an option to ucf.)

-- 
.''`.  Josselin Mouette
: :' :
`. `'
  `-


--
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/1336919442.2522.2.camel@tomoe

Re: RFC: OpenRC as Init System for Debian

[Vincent Bernat]

OoO  Pendant le  journal télévisé  du samedi  12 mai  2012,  vers 20:58,
Thomas Goirand  disait :

>> The advantage of having the defaults in a file is that it makes it much
>> easier to inspect them. A .h file would typically not be installed, so
>> it wouldn't be readily available. In addition to that, it is much less
>> expressive. The nice thing about storing the default values in the same
>> format used by the configuration file is that if you find a default that
>> you'd like to change, you immediately know what to put in the
>> configuration file in order to change it.
>> 
> Then why not simply write this in /usr/share/doc//examples ?

Because they  are the  defaults of the  application, not  examples. This
conversation is going nowhere.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

 /* Thanks to Rob `CmdrTaco' Malda for not influencing this code in any
  * way.
  */
2.4.3 linux/net/core/netfilter.c


pgppM9vVpexlQ.pgp
Description: PGP signature

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/12/2012 10:02 PM, Nikolaus Rath wrote:
> The advantage of having the defaults in a file is that it makes it much
> easier to inspect them. A .h file would typically not be installed, so
> it wouldn't be readily available. In addition to that, it is much less
> expressive. The nice thing about storing the default values in the same
> format used by the configuration file is that if you find a default that
> you'd like to change, you immediately know what to put in the
> configuration file in order to change it.
>   
Then why not simply write this in /usr/share/doc//examples ?

Thomas


-- 
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/4faeb2b9.1080...@debian.org

Re: RFC: OpenRC as Init System for Debian

[Nikolaus Rath]

Thomas Goirand  writes:
> On 05/11/2012 05:07 PM, Gergely Nagy wrote:
>> I'll turn this around: how do you handle cases where the defaults of
>> packages like apt, exim or syslogd change? Where the defaults are
>> embedded in the executable.
>>   
> The thing is, if you put the default in a file, it's because you
> expect these to change, at least more often than things that
> are compiled-in. Otherwise, what's the point in having stuff
> stored in a file that can be edited? Why not just do a .h with
> the values you need?

The advantage of having the defaults in a file is that it makes it much
easier to inspect them. A .h file would typically not be installed, so
it wouldn't be readily available. In addition to that, it is much less
expressive. The nice thing about storing the default values in the same
format used by the configuration file is that if you find a default that
you'd like to change, you immediately know what to put in the
configuration file in order to change it.


Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-- 
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/87k40hh502@vostro.rath.org

Re: RFC: OpenRC as Init System for Debian

[Roger Leigh]

On Sat, May 12, 2012 at 05:25:57PM +0800, Thomas Goirand wrote:
> On 05/11/2012 05:07 PM, Gergely Nagy wrote:
> > I'll turn this around: how do you handle cases where the defaults of
> > packages like apt, exim or syslogd change? Where the defaults are
> > embedded in the executable.
> >   
> The thing is, if you put the default in a file, it's because you
> expect these to change, at least more often than things that
> are compiled-in. Otherwise, what's the point in having stuff
> stored in a file that can be edited? Why not just do a .h with
> the values you need?
> 
> P.S: I'm continuing to ask, even though you guys are slowly
> succeeding in convincing me... :) Not fully though... which
> is why I'm continuing this (I believe interesting) discussion.

At this point, I think all the pros and cons of all the various
different strategies have been discussed ad nauseam--there's not
much of value in continuing this further on this list.  It's not
adding anything new or useful.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120512113200.gr23...@codelibre.net

Re: RFC: OpenRC as Init System for Debian

[Michael Biebl]

On 12.05.2012 11:21, Thomas Goirand wrote:
> By the way, I finally found the time to try systemd, and I was
> shocked to see how fast it booted! :)
> The only thing is that I had no clue what started: nothing were
> prompted on my screen. Is there a way to have it more verbose?

1/ Remove "quiet" from the kernel command line. This also has influence
on the verbosity of the kernel itself. If you don't like the kernel message:
2/ Add "systemd.sysv_console=true systemd.show_status=true" to the
kernel command line.

man 1 systemd → "KERNEL COMMAND LINE"

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: RFC: OpenRC as Init System for Debian

[Jon Dowland]

On Sat, May 12, 2012 at 05:21:03PM +0800, Thomas Goirand wrote:
> By the way, I finally found the time to try systemd, and I was
> shocked to see how fast it booted! :)
> The only thing is that I had no clue what started: nothing were
> prompted on my screen. Is there a way to have it more verbose?

This is probably better directed at a user-oriented list, or a systemd
specific list. (Although I have seen the answer posted in this thread
at least once.)


-- 
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/20120512110535.GB30842@debian

Re: RFC: OpenRC as Init System for Debian

[Gergely Nagy]

Thomas Goirand  writes:

> On 05/12/2012 03:19 AM, Gergely Nagy wrote:
>> It's perfectly able to notice changes
>> in /lib/systemd too, or pretty much anywhere else.
>>   
> I thought these were only default which we shouldn't
> have to care about?!? :)

You don't change defaults, but if you get notified when they do change,
that's nice. I personally don't care, because there's only two things I
override (syslog.service and media.mount), and I couldn't care less of
the default in either case. :P

But since there were a lot of "but if it changes I get no
notification!!!1!" shoutings going on in here, I figured I'll mention
that this solution is suitable for that notification purpose as well.

It will notify you of all two cases that'll happen in the next year or
two! >:)

-- 
|8]


-- 
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/87havl8xy2@luthien.mhp

Re: RFC: OpenRC as Init System for Debian

[Gergely Nagy]

Thomas Goirand  writes:

> On 05/12/2012 03:29 AM, Gergely Nagy wrote:
>> It's not etc-overrides-lib that is the problem. It's defaults changing
>> without notice that is.
>
> Then, let me ask this:
> Do you expect that systemd's default in /lib will change often?

Nope.

> The only thing is that I had no clue what started: nothing were
> prompted on my screen. Is there a way to have it more verbose?

If you remove 'quiet' from the kernel command line, yes.

-- 
|8]


-- 
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/87obpt8y4x@luthien.mhp

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/11/2012 05:07 PM, Gergely Nagy wrote:
> I'll turn this around: how do you handle cases where the defaults of
> packages like apt, exim or syslogd change? Where the defaults are
> embedded in the executable.
>   
The thing is, if you put the default in a file, it's because you
expect these to change, at least more often than things that
are compiled-in. Otherwise, what's the point in having stuff
stored in a file that can be edited? Why not just do a .h with
the values you need?

Thomas

P.S: I'm continuing to ask, even though you guys are slowly
succeeding in convincing me... :) Not fully though... which
is why I'm continuing this (I believe interesting) discussion.


-- 
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/4fae2ca5.8020...@debian.org

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/12/2012 03:29 AM, Gergely Nagy wrote:
> It's not etc-overrides-lib that is the problem. It's defaults changing
> without notice that is.

Then, let me ask this:
Do you expect that systemd's default in /lib will change often?

By the way, I finally found the time to try systemd, and I was
shocked to see how fast it booted! :)
The only thing is that I had no clue what started: nothing were
prompted on my screen. Is there a way to have it more verbose?

Thomas


-- 
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/4fae2b7f.3000...@debian.org

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/12/2012 03:19 AM, Gergely Nagy wrote:
> It's perfectly able to notice changes
> in /lib/systemd too, or pretty much anywhere else.
>   
I thought these were only default which we shouldn't
have to care about?!? :)

Thomas


-- 
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/4fae2a5c.6090...@debian.org

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/12/2012 03:19 AM, Gergely Nagy wrote:
> The solution, however, is very simple: wrap dpkg calls, and have a list
> of files to watch for. Whenever a package touches a file that's on the
> list, fire a trigger, that can run a hook. Said hook can be something
> provided by etckeeper or similar, that would extract the appropriate
> file from the deb, and commit it to the upstream branch of /etc, for
> example.
>   
I like the idea of using Git. Because a new configuration file
with new values would simply get merged with Git, who is quite
smart about doing such merges. Only in complicated merge
conflicts, we'd have to manually solve the issue. For such merge
problems, it'd be great to simply pop a text editor so the user
can decide how to solve the merge conflict.

Thomas


-- 
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/4fae2a10.8060...@debian.org

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/12/2012 01:34 AM, Jean-Christophe Dubacq wrote:
> I think it would be really great to have some program being able to
> output all manual differences to all /etc files really useful for
> maintenance. I used to do that, but some rapidly evolving configuration
> files make it quickly unmaintainable (php.ini comes to mind: I always
> have to put back the upload_max_filesize to a superior value, and this
> one-line difference makes something that should be really, really simple
> (upgrading php, even using stable+security) a pain because one gets
> manually prompted about the differences, even if they are trivial to merge.
>   
Yes, I truly agree with the above. We need something to handle changes
better than what we have currently.

Thomas


-- 
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/4fae2952.3040...@debian.org

Re: RFC: OpenRC as Init System for Debian

[Andreas Metzler]

Uoti Urpala  wrote:
> George Danchev wrote:
[...]
>> For some reason or another the vast majority of applications have
>> not been following this approach. I'm not going to argue whether is
>> makes sense or not.

> The reason why most old applications do not follow that approach (at
> least not yet) is pretty obvious: their authors never considered it.
> etc-overrides-lib semantics have only become a seriously considered
> alternative fairly recently.

Having settings in one (optional) file overide settings in another
one is far from being a new/fresh idea though. See pine.

cu andreas


-- 
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/npi189-n4l@argenau.downhill.at.eu.org

Re: Configuration file handling (was: RFC: OpenRC as Init System for Debian)

[Guillem Jover]

On Fri, 2012-05-11 at 13:41:32 +0100, Roger Leigh wrote:
> On Fri, May 11, 2012 at 11:53:34AM +0100, Steve McIntyre wrote:
> > Jean-Christophe Dubacq wrote:
> > >If dpkg kept a copy of the original configuration file (to be retrieved
> > >at all times), it would be easier to spot local changes.
> > >I use etckeeper to do that, but it's a bit tiresome to isolate all local
> > >changes (I have to save the diffs somewhere) (and a lost hope if you do
> > >install etckeeper late in the workstation life). My  git-fu is probably
> > >not good enough (I am probably looking for a "pristine" branch and a
> > >rebased "local" branch used in production).
> > 
> > You might be interested in a proposal at UDS this week:
> > 
> > https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-dpkg-pristine-conffiles

I've just skimmed over this, and at first sight I'm not planning on
merging something like that into dpkg.

> I would much rather we had a more general mechanism of storing the
> real configuration files (as opposed to just md5s) by dpkg itself,
> which would enable proper merging of admin changes between old and
> new conffiles, and perhaps also allow dpkg to implement ucf-like
> conffile handling (or remove the need for ucf entirely).  These
> could be stored under /var/lib/dpkg/conffiles (for example).

This has been discussed before, it's on dpkg's roadmap, there's even
some draft code by Sean Finney, but the semantics where not right. I
started reworking it some time ago, and it's on my short term TODO,
either for 1.16.x or 1.17.x.

regards,
guillem


-- 
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/20120512020303.ga23...@gaara.hadrons.org

Re: RFC: OpenRC as Init System for Debian

[Marvin Renich]

* Steve Langasek  [120511 16:17]:
> On Fri, May 11, 2012 at 11:08:32AM -0400, Marvin Renich wrote:
> > The FHS is very specific that /etc is for *Host-specific* system
> 
> No, this is a total retcon.  When the FHS was written, this was definitely
> NOT a shared understanding of a difference between "host-specific
> configuration" and "upstream defaults / distribution-specific
> configuration".

I obviously read more into "host-specific" than was intended.

> Distribution defaults still would go in /etc whenever it was expected that
> an admin might want to edit the file.  This has been the convention for more
> than a decade.

Agree completely.  See the next sentence.

> > Files containing distribution-specific defaults, whether they match some
> > definition of "configuration file" or not, do not belong here unless the
> > they are also intended to be edited by the local sysadmin.
> 
> Yes.  The issue is not that either system is a violation of the standard,
> because intent is relevant here.  If the upstream *intends* the file to be a
> template that's overridden using a separate file, then /usr is the right
> place.  If the upstream intends the user to edit the provided file to make
> their changes, it belongs in /etc.  If the defaults are built into the
> binary, that's perfectly fine too.

I agree completely.  I was responding specifically to the assertion that
the definition of "configuration file" from Wikipedia meant that Debian
"must" put files containing distribution-specific defaults in /etc,
regardless of whether or not they were intended to be modified by the
local sysadmin.

> What *is* an issue is when upstreams decide to ship their defaults in /usr,
> but require users to duplicate information between /usr templates and /etc
> config files and ignore the contents of /usr in favor of the contents of
> /etc.  This is also not a violation of FHS, but it IS a crappy design.

Again, I agree completely.  See the part of my message that you did not
include where I clarified to which etc-overrides-non-etc model I was
referring.

> When software is not able to override configuration *settings* with fine
> granularity via /etc, the entire thing should go under /etc.  Doing
> otherwise makes this horrible for upgrades.

Absolutely.  Again, see my clarification of how I was using
etc-overrides-non-etc.  I did not go into what I think is wrong with
"default in /usr, copy entirety to /etc and edit in order to override a
single setting" because I was specifically trying to address the other
poster's assertion that placing anything that matches the Wikipedia
definition of "configuration file" anywhere other than /etc was a
violation of a "must" in Debian policy.

...Marvin


-- 
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/20120511210825.gc7...@cleo.wdw

Re: RFC: OpenRC as Init System for Debian

[Russ Allbery]

Steve Langasek  writes:

> What *is* an issue is when upstreams decide to ship their defaults in
> /usr, but require users to duplicate information between /usr templates
> and /etc config files and ignore the contents of /usr in favor of the
> contents of /etc.  This is also not a violation of FHS, but it IS a
> crappy design.

> When software is not able to override configuration *settings* with fine
> granularity via /etc, the entire thing should go under /etc.  Doing
> otherwise makes this horrible for upgrades.

Yes, this, with the caveat that coming up with a new tool that would do
the right thing, as Tollef discussed, would be a reasonable substitute for
putting everything in /etc.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87sjf6ih8l@windlord.stanford.edu

Re: RFC: OpenRC as Init System for Debian

[Steve Langasek]

On Fri, May 11, 2012 at 11:08:32AM -0400, Marvin Renich wrote:
> The FHS is very specific that /etc is for *Host-specific* system
> configuration, not upstream defaults or distribution-specific
> configuration.  The clear intent is that this is where files that are
> intended to be modified by the local system administrator are placed.

No, this is a total retcon.  When the FHS was written, this was definitely
NOT a shared understanding of a difference between "host-specific
configuration" and "upstream defaults / distribution-specific
configuration".

Distribution defaults still would go in /etc whenever it was expected that
an admin might want to edit the file.  This has been the convention for more
than a decade.

> Files containing distribution-specific defaults, whether they match some
> definition of "configuration file" or not, do not belong here unless the
> they are also intended to be edited by the local sysadmin.

Yes.  The issue is not that either system is a violation of the standard,
because intent is relevant here.  If the upstream *intends* the file to be a
template that's overridden using a separate file, then /usr is the right
place.  If the upstream intends the user to edit the provided file to make
their changes, it belongs in /etc.  If the defaults are built into the
binary, that's perfectly fine too.

What *is* an issue is when upstreams decide to ship their defaults in /usr,
but require users to duplicate information between /usr templates and /etc
config files and ignore the contents of /usr in favor of the contents of
/etc.  This is also not a violation of FHS, but it IS a crappy design.

When software is not able to override configuration *settings* with fine
granularity via /etc, the entire thing should go under /etc.  Doing
otherwise makes this horrible for upgrades.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: RFC: OpenRC as Init System for Debian

[Gergely Nagy]

Tollef Fog Heen  writes:

> ]] Gergely Nagy 
>
>> Tollef Fog Heen  writes:
>> 
>> > ]] Gergely Nagy 
>
>> >> In that case, the including file can be changed (by the admin) to be a
>> >> separate file, that does not include, and get the usual conffile
>> >> conflict dpkg prompt.
>> >
>> > How would that work?
>> >
>> > I have /lib/systemd/system/foo.service and want to change something in
>> > it, I then create /etc/systemd/system/foo.service with a copy of the
>> > /lib one plus whatever changes I want.
>> >
>> > The version in /lib is then updated.  How is the admin notified?
>> 
>> NEWS.Debian, like with any significant default change.
>
> So you won't get the dpkg conffile conflict prompt, then?  Can you
> explain what the scenario you talked about would look like, since it's
> apparently not the scenario I was thinking about?

I believe we're talking about the same scenario, and I was hasty to
suggest that NEWS.Debian is the only way - see below.

>> Other than that, the best I can think of is keeping track of what
>> version of the package a default changed in, and triggering something
>> from preinst, when upgrading from a version that is older than the
>> change.
>
> This is basically what the tool I'm suggesting to write will do.

During my trip back home, I wrote that tool. It's very crude and hackish
at the moment, but with a little bit of support from, say, apt (or
perhaps dpkg, but that's less likely), it could be made into something
nice.

Basically, I divert dpkg, and catch all -i calls, see what debs we're
called on, list the files therein. If any of the files are on the
watchlist, I launch the triggers, with apropriate parameters. The only
trigger I have implemented so far will extract the files that triggered
it, and put them in version control, onto the appropriate upstream
branch. Then proceed on.

I could enhance it to abort the installation, or send mail, or pause and
do some ucf magic, to check whether overrides in /etc exist at all, and
so on and so forth.

I only needed the shovel-into-a-vcs-branch thing, so that's what I
have. Adding the rest isn't hard, either.

The advantage here, is that the packager need not keep track of what
changed in which version, and admins can extend the watchlist, and
change the triggered actions too, to make it better suit their own
needs. This also means that in case of bugs, we don't need to fix
maintainer scripts, just a single application.

-- 
|8]


-- 
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/87aa1eqz1g@luthien.mhp

Re: RFC: OpenRC as Init System for Debian

[Gergely Nagy]

Thomas Goirand  writes:

> On 05/11/2012 11:08 PM, Marvin Renich wrote:
>> For clarity, the etc-overrides-non-etc model that I am talking about is
>> where the file in /etc can override individual values, not where the
>> file in /etc must replace the entirety of the non-etc configuration.
>>   
> This case is much much more acceptable to me. I wouldn't see any
> problem with it. I just don't want that new configuration values to be
> silently ignored upon upgrades, that's all I'm saying.

I agree, that seeing the defaults change would be lovely. With the
defaults being in /lib, it's possible to write a tool that notifies you.

With the defaults being in a monolithic blob, possibly inside a binary,
it is not.

-- 
|8]


-- 
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/87ehqqqzeu@luthien.mhp

Re: RFC: OpenRC as Init System for Debian

[Gergely Nagy]

SEEWEB - Marco d'Itri  writes:

> But this is a user error. The point is that with etc-overrides-lib there 
> is no prompt at all when the upstream configuration changes.

Bzzt. There's no prompt ever when upstream defaults change. Unless *all*
the defaults are laid out in /etc, *AND* the user modified that
particular file.

If suddenly /etc/$program.conf, which I never modified changes, and I
have custom snippets under /etc/$program.d/*.conf, those snippets might
very well break.

Do I get a prompt? No. The closest I get is that $program.conf was
upgraded. I see no diff, unless I keep track of my /etc in other ways.

-- 
|8]


-- 
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/87ipg2qzmc@luthien.mhp

Re: RFC: OpenRC as Init System for Debian

[Vincent Bernat]

OoO Peu  avant le début  de l'après-midi du  vendredi 11 mai  2012, vers
13:20, Gergely Nagy  disait :

>>> In other words, it does *exactly* the same thing systemd is
>>> criticised for.
>>> 
>> 
>> Which doesn't mean that it's a good practice.

> Tell me what you would gain, if there were no files under /lib/systemd,
> and all of these were compiled into the binary, please. Because that's
> the other option, as you *do not* let users change the defaults. You let
> them override them, you let them configure the system. (And that *is*
> being done in /etc.)

> There are *very* few programs that come without any kind of default, and
> even less, that let you change the default too.

> apt does not let you change the defaults, nor does dpkg. Both allow you
> to change their settings, but without recompiling, you can't change the
> defaults. Same happens with systemd, the difference is that it's easier
> to see the defaults, as they're broken out into files that are easy to
> copy and change as needed.

Yes, that's very  true. We are just used that the  kind of "defaults" in
init to  be in /etc. But  nothing is set  in stone. I was  first against
this etc-override-lib  behaviour but your  arguments are sound and  I am
now convinced that we should keep the way systemd is doing things.

Moreover, in the case of systemd, there are other mechanisms that can be
used to customize a configuration file for the more common modifications
(handling  dependencies and  ordering) using  symbolic links.  This way,
there  is  no need  to  copy  the  file from  /lib  in  /etc to  do  the
modifications.

Still in the  case of systemd, a README put in  /etc/systemd may be used
to explain  the whole etc-override-lib  to users that are  not expecting
such behaviour. A README is not a configuration file but there is one in
/etc/init.d as well.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

#if 0
2.2.16 /usr/src/linux/fs/buffer.c


pgpOoyGiMli3V.pgp
Description: PGP signature

Re: RFC: OpenRC as Init System for Debian

[Gergely Nagy]

Thomas Goirand  writes:

> On 05/11/2012 08:33 PM, Michael Biebl wrote:
>> Am 11.05.2012 14:30, schrieb Marco d'Itri:
>>   
>>> The problem with etc-overrides-lib is that a file must be copied in 
>>> full from /lib to /etc to be modified, and then future changes to the 
>>> same file in /lib will be ignored (so maybe the package will break 
>>> because these changes are required, etc).
>>> 
>> You can either copy the file or use the .include directive (which was
>> already mentioned) and only override the settings you need.
>> So systemd provides both semantics and you can chose which one you
>> want/need.
>>
>> Michael
>>   
> But upon upgrades, it's still a silent thing. The configuration file in /lib
> is overwritten and users wont know about the changes.

Likewise for *every* other case where the default changes. There's
nothing different. Nothing. Nada.

Except you can write a tool to warn in *this* case, because the defaults
are available in a diffable format.

-- 
|8]


-- 
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/87mx5eqztf@luthien.mhp

Re: RFC: OpenRC as Init System for Debian

[Gergely Nagy]

m...@linux.it (Marco d'Itri) writes:

> On May 11, Thomas Goirand  wrote:
>
>> > Long story short, I still don't see what the fuss is about.
>> The fuss is about we're being told that there will be silent
>> overwriting of configuration files without being prompted about
>> changes, which potentially, will make it horrible to manage
>> upgrades in a decent way without knowing the corner cases.
> No, not even that: if you edit files in /lib without being aware of the 
> consequences then you are an idiot and deserve to suffer for it.
> The problem with etc-overrides-lib is that a file must be copied in 
> full from /lib to /etc to be modified, and then future changes to the 
> same file in /lib will be ignored (so maybe the package will break 
> because these changes are required, etc).

And...?

If it were somewhere under /usr/share/doc/$package/examples, how would
that be different? (Assuming that the *default* would then be wired into
the binary)

You'd still need to copy the file, and if the defaults change under you,
you're screwed. Even worse if you have to dig out the possible options,
and their defaults from (possibly stale) documentation.

But even if everything is in /etc, you can still easily screw yourself
over: conf.d/ can very easily break the exact same way.

It's not etc-overrides-lib that is the problem. It's defaults changing
without notice that is. With the defaults being broken out into files,
making a tool that notifies the user preemptively when a default will
change, and stops the upgrade, is possible, and is not even hard.

You can't do that when the defaults are either unavailable, or subject
to change by the admin.

-- 
|8]


-- 
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/87r4uqqzwt@luthien.mhp

Re: RFC: OpenRC as Init System for Debian

[Gergely Nagy]

Thomas Goirand  writes:

> Seriously, can't someone who broke his configuration wget the package,
> and use mc to get into the .deb and get the original configuration
> file???

FWIW, I'd love an easier way to keep track of my /etc, where upstream
changes and my own are on a separate branch. So the idea is not entirely
silly, and would be useful even for folk like myself, who - at least I
dare hope so - are not entirely clueless.

The solution, however, is very simple: wrap dpkg calls, and have a list
of files to watch for. Whenever a package touches a file that's on the
list, fire a trigger, that can run a hook. Said hook can be something
provided by etckeeper or similar, that would extract the appropriate
file from the deb, and commit it to the upstream branch of /etc, for
example.

Then proceed on, and do whatever else needs to be done. And boom! We
have a way to allow experienced users to keep track of their /etc
properly, that does not fall on its face when I notice a bad config
change in the upstream config two updates later.

Oh, and this whole thing need not live in /etc at all, and can follow
anything, not just config files. It's perfectly able to notice changes
in /lib/systemd too, or pretty much anywhere else.

I actually just implemented that (it took 10 minutes, becuase I screwed
up first), and will be testing how it works over the next few weeks.

-- 
|8]


-- 
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/87y5oyr0eq@luthien.mhp

Re: RFC: OpenRC as Init System for Debian

[Jean-Christophe Dubacq]

On 11/05/2012 19:03, Thomas Goirand wrote:
> On 05/12/2012 12:22 AM, Jean-Christophe Dubacq wrote:
>> I find your attitude assumes users always have the knowledge and the
>> time to investigate everything. This is not the reality.
>>
>> Sincerly,
>>   
> Not at all. Anyone without the knowledge will not be able to
> restore anything anyway.
> 
> Anyone with the knowledge will know how to get the original file.
> Yes, it will take more time to do that, but do you think this is
> the kind of operation you need to do every day? I'd say, once
> every 5 years maybe?
> 
> Very rarely, I do a purge then reinstall, but never it happened
> to me that my system was in such state that I had to recover
> by hand a configuration file, using the single user boot. Did
> this happen to you at some point? Anyone else?

Yes, several times indeed. Most times when upgrading network packages at
the same time.

> I'm not bashing the idea so much, as it is a harmless one, I just
> think it is simply a useless feature, and I don't think it's worth
> investing any human time on this.

I think it would be really great to have some program being able to
output all manual differences to all /etc files really useful for
maintenance. I used to do that, but some rapidly evolving configuration
files make it quickly unmaintainable (php.ini comes to mind: I always
have to put back the upload_max_filesize to a superior value, and this
one-line difference makes something that should be really, really simple
(upgrading php, even using stable+security) a pain because one gets
manually prompted about the differences, even if they are trivial to merge.


-- 
Jean-Christophe Dubacq



signature.asc
Description: OpenPGP digital signature

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/12/2012 12:22 AM, Jean-Christophe Dubacq wrote:
> I find your attitude assumes users always have the knowledge and the
> time to investigate everything. This is not the reality.
>
> Sincerly,
>   
Not at all. Anyone without the knowledge will not be able to
restore anything anyway.

Anyone with the knowledge will know how to get the original file.
Yes, it will take more time to do that, but do you think this is
the kind of operation you need to do every day? I'd say, once
every 5 years maybe?

Very rarely, I do a purge then reinstall, but never it happened
to me that my system was in such state that I had to recover
by hand a configuration file, using the single user boot. Did
this happen to you at some point? Anyone else?

I'm not bashing the idea so much, as it is a harmless one, I just
think it is simply a useless feature, and I don't think it's worth
investing any human time on this.

Thomas


-- 
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/4fad4670.5030...@debian.org

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/11/2012 11:08 PM, Marvin Renich wrote:
> For clarity, the etc-overrides-non-etc model that I am talking about is
> where the file in /etc can override individual values, not where the
> file in /etc must replace the entirety of the non-etc configuration.
>   
This case is much much more acceptable to me. I wouldn't see any
problem with it. I just don't want that new configuration values to be
silently ignored upon upgrades, that's all I'm saying.

Thomas


-- 
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/4fad3cb8.1080...@debian.org

Re: RFC: OpenRC as Init System for Debian

[Jean-Christophe Dubacq]

On 11/05/2012 15:29, Thomas Goirand wrote:

> The setting of unix rights 0440 is indeed very amusing.

Yes. Maybe the mean to chmod a-w everything, for some applications will
not work with so large modes (sudo, for example).

> The only nice point about this proposal is that it's going to make happy
> hard drive factories: they will be able to sell bigger hard drive for no
> valid
> good reasons.

Come on! Less than 20M, it could trivially be compressed.

> Seriously, can't someone who broke his configuration wget the package,
> and use mc to get into the .deb and get the original configuration file???

Not necessarily.

1) Many configuration files are dynamically generated through debconf
questions, which root may not be able to rerun to obtain the same result.
2) What if you borked your network configuration? What if the
malfunction is due to a complex interaction between several packages
(let's say, a FORCESSL option on some service A, and a libssl upgrade
breaks A but only if the FORCESSL option is used?) Being able
3) I think etckeeper could do the job without much development. However,
it will make the hard drive factories happy (according to you).

> Overall, all this proposal assumes that users are idiots who love to change
> things they don't understand, and aren't smart enough to restore. I can't
> believe that newbies favorite game would be changing randomly the
> content of /etc/init. And at the same time, I can't believe that experts
> tweaking upstart jobs wouldn't know how to restore them.

I find your attitude assumes users always have the knowledge and the
time to investigate everything. This is not the reality.

Sincerly,
-- 
Jean-Christophe Dubacq



signature.asc
Description: OpenPGP digital signature

Re: RFC: OpenRC as Init System for Debian

[Russ Allbery]

Thomas Goirand  writes:

> Section 10.7.2 of dpm:

> "Any configuration files created or used by your package must reside in
> |/etc|."

"Configuration file" is a term of art that is previously defined in the
Policy document.  It doesn't mean what you're taking it to mean.

There isn't anything about etc-overrides-lib that violates the letter of
Policy.  (The expectations of a Debian administrator are another
question.)

-- 
Russ Allbery (r...@debian.org)   


-- 
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/8739767l76@windlord.stanford.edu

Re: RFC: OpenRC as Init System for Debian

[Marvin Renich]

* Thomas Goirand  [120511 04:45]:
> On 05/11/2012 04:04 AM, David Weinehall wrote:
> From: http://en.wikipedia.org/wiki/Configuration_file
> 
> "In computing, configuration files, or config files configure the initial
> settings for some computer programs. They are used for user applications,
> server processes and operating system settings."
> 
> The fact that these files are in /lib and shouldn't be touched by the admin
> doesn't make them less configuration files. They still match the above
> definition from Wikipedia.
> 
> > And debian-policy isn't set in stone.
> > Otherwise it wouldn't have last been revised in February 2012 :)
> >   
> 
> The debian-policy maybe, but the FHS, and config files in /etc *is* a very
> strong policy that you will not change in Debian, and for very valid
> reasons already described in this thread.

The FHS is very specific that /etc is for *Host-specific* system
configuration, not upstream defaults or distribution-specific
configuration.  The clear intent is that this is where files that are
intended to be modified by the local system administrator are placed.
Files containing distribution-specific defaults, whether they match some
definition of "configuration file" or not, do not belong here unless the
they are also intended to be edited by the local sysadmin.

Using a Wikipedia definition must be done with careful consideration, as
they are often either over generalized or too specific.  In this case I
believe the Wikipedia definition is not in the least relevant to the
subtleties being disputed here.

Debian policy does not explicitly differentiate between host-specific
configuration and Debian-provided default configuration, but it does
say, "Typically, configuration files are intended to be modified by the
system administrator (if needed or desired) to conform to local policy
or to provide more useful site-specific behavior."

Following the FHS is, however, a "must" in Debian policy except where
policy explicitly provides an exception or conflicts with the FHS.

It is clear to me that etc-overrides-non-etc is perfectly compliant with
Debian policy as long as the sysadmin does not need to modify the
non-etc files to obtain the desired behavior.

I have been using Debian since 1998, and IME the cases where changes to
the Debian-supplied configuration files would have caused breakage if
the Debian defaults had been in /usr/lib/package and only local
modifications were in /etc have been rare.  On the other hand, the cases
where this model would have both obviated the need for a manual merge
and resulted in exactly the configuration I intended are extremely
common.

Gergely Nagy has shown elsewhere in this thread that no matter which
configuration model you use, there are cases where you might not get a
notification of incompatible default configuration from dpkg on upgrade.
On the other hand, the etc-overrides-non-etc model significantly
simplifies most of the common default-configuration-change cases.

For clarity, the etc-overrides-non-etc model that I am talking about is
where the file in /etc can override individual values, not where the
file in /etc must replace the entirety of the non-etc configuration.

While I agree that etc-overrides-non-etc may not be the best model for
all software, it is the best for some and at least as good for many
other packages.

...Marvin


-- 
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/20120511150832.ga7...@cleo.wdw

Re: RFC: OpenRC as Init System for Debian

[Nikolaus Rath]

m...@linux.it (Marco d'Itri) writes:
> On May 11, Nikolaus Rath  wrote:
>
>> > Wrong: since you have to copy the whole file to override it, and files 
>> > in /lib have no conffiles handling, after an upgrade you will not know 
>> > what was changed by you and what was changed upstream.
>> I think everyone here agrees with that. The interesting case is when
>> files in /etc/ can either explicitly include the /lib file, or
>> implicitly override the /lib settings.
> I do not know about any package which work this way,

Well, systemd has been mentioned one or two times here in the last
weeks.

> but there is any 
> then the problem is not different from packages which support multiple 
> configuration file fragments in /etc, ship the default configuration 
> in /etc and allow it to be modified by other configuration fragments in 
> /etc (e.g. Apache).

I agree, and therefore I'm surprised that some people are getting so
aggravated about this if the default configuration is installed in /lib
rather than /etc.


Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-- 
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/8762c27shc@inspiron.ap.columbia.edu

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/11/2012 07:04 PM, Gergely Nagy wrote:
> Steve McIntyre  writes:
>
>   
>> Jean-Christophe Dubacq wrote:
>> 
>>> If dpkg kept a copy of the original configuration file (to be retrieved
>>> at all times), it would be easier to spot local changes.
>>> I use etckeeper to do that, but it's a bit tiresome to isolate all local
>>> changes (I have to save the diffs somewhere) (and a lost hope if you do
>>> install etckeeper late in the workstation life). My  git-fu is probably
>>> not good enough (I am probably looking for a "pristine" branch and a
>>> rebased "local" branch used in production).
>>>   
>> You might be interested in a proposal at UDS this week:
>>
>> https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-dpkg-pristine-conffiles
>> 
> So basically, we'd have a directory of files under /etc that are not
> conffiles, and even made 0440. Amusing proposal.
>
> Why not move them outside of /etc then, if they are not configuration
> files, and should not be touched by the user?
>
> (Yeah, sure, they can be moved out of /etc, but that doesn't stop the
> original proposal being amusing, sorry.)
>   
The setting of unix rights 0440 is indeed very amusing.

The only nice point about this proposal is that it's going to make happy
hard drive factories: they will be able to sell bigger hard drive for no
valid
good reasons.

Seriously, can't someone who broke his configuration wget the package,
and use mc to get into the .deb and get the original configuration file???

Overall, all this proposal assumes that users are idiots who love to change
things they don't understand, and aren't smart enough to restore. I can't
believe that newbies favorite game would be changing randomly the
content of /etc/init. And at the same time, I can't believe that experts
tweaking upstart jobs wouldn't know how to restore them.

Thomas


-- 
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/4fad144c.1050...@debian.org

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/11/2012 08:28 PM, David Weinehall wrote:
> Talking about yourself in pluralis majestatis now?
> Yes, I get it that you are.  Or are you somehow assuming that you can
> speak for all of Debian?  I guess you're aware of the fact that I'm a DD
> too?
>   
By reading other replies, I thought there was only yourself and Uoti.
Now I can see that Gergely is also on your side, and then I don't
think there's a large consensus anymore.

Thomas


-- 
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/4fad11f1.40...@debian.org

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/11/2012 08:33 PM, Michael Biebl wrote:
> Am 11.05.2012 14:30, schrieb Marco d'Itri:
>   
>> The problem with etc-overrides-lib is that a file must be copied in 
>> full from /lib to /etc to be modified, and then future changes to the 
>> same file in /lib will be ignored (so maybe the package will break 
>> because these changes are required, etc).
>> 
> You can either copy the file or use the .include directive (which was
> already mentioned) and only override the settings you need.
> So systemd provides both semantics and you can chose which one you
> want/need.
>
> Michael
>   
But upon upgrades, it's still a silent thing. The configuration file in /lib
is overwritten and users wont know about the changes.

Thomas


-- 
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/4fad0fc2.4010...@debian.org

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/11/2012 08:30 PM, Marco d'Itri wrote:
> On May 11, Thomas Goirand  wrote:
>
>   
>>> Long story short, I still don't see what the fuss is about.
>>>   
>> The fuss is about we're being told that there will be silent
>> overwriting of configuration files without being prompted about
>> changes, which potentially, will make it horrible to manage
>> upgrades in a decent way without knowing the corner cases.
>> 
> No, not even that: if you edit files in /lib without being aware of the 
> consequences then you are an idiot and deserve to suffer for it.
> The problem with etc-overrides-lib is that a file must be copied in 
> full from /lib to /etc to be modified, and then future changes to the 
> same file in /lib will be ignored (so maybe the package will break 
> because these changes are required, etc).
>   
Yes, that's exactly what I don't like, and what I want to avoid!!!

I want to be prompted, shown a diff, so I can see what's going on, and then
take my own decision based on this diff. So, in fewer words: the current
normal behavior in Debian.

Thomas


-- 
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/4fad0f7a.2020...@debian.org

Re: RFC: OpenRC as Init System for Debian

[SEEWEB - Marco d'Itri]

On May 11, Michael Biebl  wrote:

> You can either copy the file or use the .include directive (which was
> already mentioned) and only override the settings you need.
Not with udev or kmod.

> > The problem with etc-overrides-lib is that a file must be copied in 
> > full from /lib to /etc to be modified, and then future changes to the 
> > same file in /lib will be ignored (so maybe the package will break 
> > because these changes are required, etc).
> This argument goes both ways, though. I've received more than one bug
> report about uses fiddling with their sysv init scripts, then blindly
> pressing ok during the upgrade or using non-interactive mode (which kept
> the locally modified version) and the daemon failed to start due to
> required changes being missing in the locally modified version.
But this is a user error. The point is that with etc-overrides-lib there 
is no prompt at all when the upstream configuration changes.
This is good for Red Hat, because they can guarantee that no relevant 
changes will appear until the next major release, but is bad for us who 
actually support system upgrades.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: RFC: OpenRC as Init System for Debian

[Tollef Fog Heen]

]] Gergely Nagy 

> Tollef Fog Heen  writes:
> 
> > ]] Gergely Nagy 

> >> In that case, the including file can be changed (by the admin) to be a
> >> separate file, that does not include, and get the usual conffile
> >> conflict dpkg prompt.
> >
> > How would that work?
> >
> > I have /lib/systemd/system/foo.service and want to change something in
> > it, I then create /etc/systemd/system/foo.service with a copy of the
> > /lib one plus whatever changes I want.
> >
> > The version in /lib is then updated.  How is the admin notified?
> 
> NEWS.Debian, like with any significant default change.

So you won't get the dpkg conffile conflict prompt, then?  Can you
explain what the scenario you talked about would look like, since it's
apparently not the scenario I was thinking about?

> Other than that, the best I can think of is keeping track of what
> version of the package a default changed in, and triggering something
> from preinst, when upgrading from a version that is older than the
> change.

This is basically what the tool I'm suggesting to write will do.

> This however, requires a lot of manual work, might aswell shovel the
> whole thing from under /lib to /etc then, but then we still didn't solve
> the problem: suppose there is a unit file that supports starting
> multiple instances, by way of symlinking. I start to use this feature,
> I change nothing, just symlink files around. At some point, this feature
> gets removed, my upgrade succeeds, but my instances won't start anymore,
> and the best notification I have is something that scrolled by that a
> conffile was upgraded.

You'll get a notification, since the file will have changed, then.

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


-- 
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/87boluopkt@qurzaw.varnish-software.com

Re: RFC: OpenRC as Init System for Debian

[Michael Biebl]

Am 11.05.2012 14:30, schrieb Marco d'Itri:
> The problem with etc-overrides-lib is that a file must be copied in 
> full from /lib to /etc to be modified, and then future changes to the 
> same file in /lib will be ignored (so maybe the package will break 
> because these changes are required, etc).

This argument goes both ways, though. I've received more than one bug
report about uses fiddling with their sysv init scripts, then blindly
pressing ok during the upgrade or using non-interactive mode (which kept
the locally modified version) and the daemon failed to start due to
required changes being missing in the locally modified version.

Also, the recent discussions somehow make it look like you constantly
need to change the systemd .service files. This should only be necessary
in the rarest of cases.
Those systemd .service are in the vast majority of cases really simple
(most just containing the path to the executable and the type) and
comparable in complexity with dbus (system-)service files which have
been installed in /usr/share/dbus/ forever.

Michael



signature.asc
Description: OpenPGP digital signature

Re: RFC: OpenRC as Init System for Debian

[Gergely Nagy]

Thomas Goirand  writes:

> On 05/11/2012 06:39 PM, Gergely Nagy wrote:
>> Long story short, I still don't see what the fuss is about.
>>   
> The fuss is about we're being told that there will be silent
> overwriting of configuration files without being prompted about
> changes, which potentially, will make it horrible to manage
> upgrades in a decent way without knowing the corner cases.

There will be no overwriting of configuration files. There might be
changes to defaults, like in every piece of software that is out there.

When defaults change, unless care is being taken, things will break,
indeed. That is not specific to systemd, and has nothing to do with its
defaults being under /lib/systemd.

Let me tell you three scenarios, just to demonstrate what I'm getting
at:

We have three programs:

* We have a program, that has a few defaults compiled in, and reads its
  configuration from /etc/program.conf. Lets call this the 'def-etc'
  program.

* We have another, that has no built in defaults, ships a config file in
  /etc/program/defaults.conf, and includes snippets from
  /etc/program/conf.d/. We'll call this 'def-conf.d'.

* We have a third program that comes with no compiled-in defaults, but
  has them in /lib/program instead. It reads configuration from snippets
  under /etc/program/. We'll call this 'def-lib'.

In the first case, since there is a single config file, lets assume we
modified that. In the other two cases, we placed snippets in the
appropriate directory, and did not touch the config file that contains
the default config.

When the first program changes its default, since it is compiled in, you
get no notofication, no prompt, no nothing - it wasn't in a config file,
it was compiled in.

When the second program changes its default, since you did not modify
the default config, that will be overwritten, and the only notice you
get is a "Configuration file updated" scrolling by, no prompt
whatsoever, no visible news, just something you've grown to expect, and
trust your tool to handle right.

When the third program changes its default, since you can't modifiy the
default config, you get no notification, no prompt, no nothing.

In all three cases, you get no prompt at all, because no tool in Debian
can handle the change of default settings. We're not prepared for that,
nor can we ever be. We can handle configuration change, but defaults are
*not* configuration. Configuration is things you're allowed to change.

> On top of that, we're being told that this is the reason why
> we should use this system, which is totally the inverse of
> what we've been doing in Debian for years.

I can't speak for anyone else who thinks etc-overrides-non-etc isn't the
work of the $devil, I merely think that this is a valid way to treat
default (unchangeable by the user) settings. It will not work for
everyone, nor should it.

But for specific cases, it is useful, and makes sense. That is all.

-- 
|8]


-- 
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/87zk9esxu3.fsf@algernon.balabit

Configuration file handling (was: RFC: OpenRC as Init System for Debian)

[Roger Leigh]

On Fri, May 11, 2012 at 11:53:34AM +0100, Steve McIntyre wrote:
> Jean-Christophe Dubacq wrote:
> >
> >If dpkg kept a copy of the original configuration file (to be retrieved
> >at all times), it would be easier to spot local changes.
> >I use etckeeper to do that, but it's a bit tiresome to isolate all local
> >changes (I have to save the diffs somewhere) (and a lost hope if you do
> >install etckeeper late in the workstation life). My  git-fu is probably
> >not good enough (I am probably looking for a "pristine" branch and a
> >rebased "local" branch used in production).
> 
> You might be interested in a proposal at UDS this week:
> 
> https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-dpkg-pristine-conffiles

I'm unconvinced that this would be workable.  How many programs and
configuration files reference absolute paths under /etc?  Which
wouldn't be overridable using the proposed mechanism.

Is this going to concern itself only with init.d scripts or all
conffiles?  Bind mounting the prinstine copy over the broken copy
is probably the safest way--it keeps all the paths consistent, though
you'd lose /all/ configuration if you bind over the whole /etc rather
than just parts of it.  A unionfs overlay might also be an option, then
the /etc-only files can show through; but all these are still far too
fragile for my liking.

I would much rather we had a more general mechanism of storing the
real configuration files (as opposed to just md5s) by dpkg itself,
which would enable proper merging of admin changes between old and
new conffiles, and perhaps also allow dpkg to implement ucf-like
conffile handling (or remove the need for ucf entirely).  These
could be stored under /var/lib/dpkg/conffiles (for example).  For
the "pristine" initscripts use case, it would be possible to
mirror a subset under /lib or /etc.  But how often does anyone
make their system unbootable even with the most extreme init
script hacking?  We already have rescue boot CDs etc. to cater for
this eventuality in any case--why introduce a pile of complexity
into the system when it's already redundant?

On a related note...
While we might criticise rpm for its bad conffile handling, dpkg is
itself fairly woeful, and if we change one thing for wheezy+1, it
should be sane conffile handling.  dpkg should never "forget" about
conffiles; the fact that maintainer scripts have to take care of
purging such files is a glaring defect, and possibly the source of
the greatest fragility in our maintainer scripts--it's impossible for
maintainer scripts to get this right all the time given all the
corner cases like downgrades and being taken over by other packages.
If this was implemented robustly, the maintainer script should never
need to concern itself with such cleanup, or indeed any manual work
with conffiles at all, except maybe for deletion ahead of purge
where this is needed.  And given the frequency this is needed, a
defined mechanism to do this would be useful.


Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120511124132.gn23...@codelibre.net

Re: RFC: OpenRC as Init System for Debian

[Michael Biebl]

Am 11.05.2012 14:30, schrieb Marco d'Itri:
> The problem with etc-overrides-lib is that a file must be copied in 
> full from /lib to /etc to be modified, and then future changes to the 
> same file in /lib will be ignored (so maybe the package will break 
> because these changes are required, etc).

You can either copy the file or use the .include directive (which was
already mentioned) and only override the settings you need.
So systemd provides both semantics and you can chose which one you
want/need.

Michael



signature.asc
Description: OpenPGP digital signature

Re: RFC: OpenRC as Init System for Debian

[Tollef Fog Heen]

]] Thomas Goirand 

> On 05/11/2012 06:39 PM, Gergely Nagy wrote:
> > Long story short, I still don't see what the fuss is about.
> >   
> The fuss is about we're being told that there will be silent
> overwriting of configuration files without being prompted about
> changes, which potentially, will make it horrible to manage
> upgrades in a decent way without knowing the corner cases.

I've not yet seen anybody saying that, so could you provide a reference,
please?  Preferably by somebody who is actually going to be doing some
of the work.

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


-- 
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/87fwb6oq1x@qurzaw.varnish-software.com

Re: RFC: OpenRC as Init System for Debian

[Marco d'Itri]

On May 11, Thomas Goirand  wrote:

> > Long story short, I still don't see what the fuss is about.
> The fuss is about we're being told that there will be silent
> overwriting of configuration files without being prompted about
> changes, which potentially, will make it horrible to manage
> upgrades in a decent way without knowing the corner cases.
No, not even that: if you edit files in /lib without being aware of the 
consequences then you are an idiot and deserve to suffer for it.
The problem with etc-overrides-lib is that a file must be copied in 
full from /lib to /etc to be modified, and then future changes to the 
same file in /lib will be ignored (so maybe the package will break 
because these changes are required, etc).

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: RFC: OpenRC as Init System for Debian

[Marco d'Itri]

On May 11, Gergely Nagy  wrote:

> Long story short, I still don't see what the fuss is about.
Apparently the reason is that you do not understand the problem, since 
you keep getting back to the not relevant issue of software which 
supports placing configuration directives in multiple directories.
This is not what "etc-overrides-lib" is about: with udev and systemd, if 
you create a file in /etc then the file with the same name in /lib is 
ignored.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: RFC: OpenRC as Init System for Debian

[David Weinehall]

On Fri, May 11, 2012 at 04:39:22PM +0800, Thomas Goirand wrote:
[snip]
> 
> From: http://en.wikipedia.org/wiki/Configuration_file
> 
> "In computing, configuration files, or config files configure the initial
> settings for some computer programs. They are used for user applications,
> server processes and operating system settings."
> 
> The fact that these files are in /lib and shouldn't be touched by the admin
> doesn't make them less configuration files. They still match the above
> definition from Wikipedia.

Since when did Wikipedia have any relevance on Debian?

> > If the old file in /lib isn't equal to the new file being installed to
> > /lib, and there's a user supplied file in /etc rather than just the
> > default (which would only include the version in lib), then prompt the
> > user.  If the user is running a non-interactive upgrade, fire off an
> > e-mail or something.  For any major changes to the /lib files (stuff
> > that are likely to trigger user actions), NEWS.Debian should of course,
> > as usual, contain a heads up.
> >   
> 
> No need to explain again, again and again the same thing. We did understand
> what your point is, but still, we don't agree with you and Uoti. Move on.

Talking about yourself in pluralis majestatis now?

> > Just because something isn't supported currently in our tools doesn't
> > make it impossible to support it.
> 
> The very reason why our tools don't support it, is because *we don't
> want it.  It's designed like this on purpose, and we are happy with
> the way things are right now.

Yes, I get it that you are.  Or are you somehow assuming that you can
speak for all of Debian?  I guess you're aware of the fact that I'm a DD
too?

> Why can't you implement something like amavis, grub2, or apache are
> doing?  Especially Amavis, where the default config is a conffile, but
> you can override what you need by using a higher number in the file
> name.
> 
> It works well, it is integrated with Debian and the way things work...

A solution with configuration files in /etc including, or overriding,
defaults elsewhere works well too.  gconf is a good example.

Tollef's example of how to handle the case of a setting that can be set
multiple times is probably needs some thought though, but that
particular case can be solved by copying rather than including, if needs
be.

Anyway, I'm neither systemd maintainer nor upstream, so I don't believe
I'm the right person to speak to.  Then again, neither are you TTBOMK :)

> > And debian-policy isn't set in stone.
> > Otherwise it wouldn't have last been revised in February 2012 :)
> >   
> 
> The debian-policy maybe, but the FHS, and config files in /etc *is* a very
> strong policy that you will not change in Debian, and for very valid
> reasons already described in this thread.

Sigh.  The config files remain in /etc.  The defaults are not.  There's
nothing in FHS that contradicts such a behaviour.


Regards: David
-- 
 /) David Weinehall  /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
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/20120511122856.gg10...@suiko.acc.umu.se

Re: RFC: OpenRC as Init System for Debian

[Uoti Urpala]

Philip Hands wrote:
> The traditional Debian approach to /etc is largely self documenting, to
> the extent that one can generally walk into a site cold and (having
> established that they have decent backups) cheerfully do an upgrade on
> their Debian servers without anything breaking (I do this regularly).

If you walk into a site cold, how do you tell if they have weird local
configuration for something? It's much easier to check if there's
something under /etc than to start checking whether the files match
what's expected for the package version, if the the default files are
always there even if nothing has been configured.

> The sources of potential breakage are highlighted by the packaging
> system, at which point you can read up on any package that needs
> attention with which you're not already familiar, while ignoring the
> ones that upgrade cleanly.

And why would this have to be any worse with etc-overrides-lib? 


> > Why would this cause problems for Debian, except at most needing some
> > changes to tools to better support this case? Or do you think
> > implementing that would be hard?
> 
> Are you volunteering to do that?
> 
> If not then stop making assertions that simply require someone else to
> do a load of work to pander to your unusual tastes.  If you are
> volunteering, then that's somewhat better (although I would prefer
> that we simply fix the packages to behave themselves in a proper Debian
> way instead).

No, I'm not volunteering, mainly because I don't want to program in
shell (which ucf seems to be implemented in). I can still estimate what
such an implementation would need to do. You can't argue that everything
which has not already been implemented would be a huge fundamental
problem. If you want to argue that etc-overrides-lib would be
fundamentally bad, hard to support, or undesirable to even try to
support in Debian, then you should say more about implementation
difficulties than just "it's not implemented at the moment".

George Danchev gave a proposed implementation of change alerts in an
earlier mail:
http://lists.debian.org/<201205110212.30503.danc...@spnet.net>

While there are things you'd want to improve in a "real" implementation
for packager convenience and better user interface (and the ucf part
looks like it'd incorrectly create the file under /etc by default), I
think that's enough to demonstrate this is not a particularly hard
problem.



-- 
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/1336737949.2227.181.camel@glyph.nonexistent.invalid

Re: RFC: OpenRC as Init System for Debian

[Gergely Nagy]

Thomas Goirand  writes:

> On 05/11/2012 06:39 PM, Gergely Nagy wrote:
>>In other words, it does *exactly* the same thing systemd is
>>criticised for.
>>   
>
> Which doesn't mean that it's a good practice.

Tell me what you would gain, if there were no files under /lib/systemd,
and all of these were compiled into the binary, please. Because that's
the other option, as you *do not* let users change the defaults. You let
them override them, you let them configure the system. (And that *is*
being done in /etc.)

There are *very* few programs that come without any kind of default, and
even less, that let you change the default too.

apt does not let you change the defaults, nor does dpkg. Both allow you
to change their settings, but without recompiling, you can't change the
defaults. Same happens with systemd, the difference is that it's easier
to see the defaults, as they're broken out into files that are easy to
copy and change as needed.

-- 
|8]


-- 
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/874nrnt155.fsf@algernon.balabit

Re: RFC: OpenRC as Init System for Debian

[Gergely Nagy]

Thomas Goirand  writes:

> On 05/11/2012 04:52 PM, Gergely Nagy wrote:
>> Neither the FHS, nor the policy says anything about etc-overrides-lib as
>> far as I can see. Neither pro or con. Do feel free to point me to the
>> relevant section, would I be mistaken.
>>   
>
> Section 10.7.2 of dpm:
>
> "Any configuration files created or used by your package must reside in
> |/etc|."
>
> The policy never talks about etc-overrides-lib configuration files, it
> only tells
> that all configuration files should go in /etc, and there's no
> exception, and
> it is also a "must".

But these are default settings, not configuration files. The
configuration files *are* in /etc. Configuration files are stuff you
want to change, defaults are things upstream (or at worst, the package
maintainer) decides them to be, and the user has no business touching
them. That is what configuration is for, to change the defaults.

That the defaults happen to be files instead of some compiled in thing,
is an implementation detail.

But be my guest, if you take this seriously, please file a bug against
X11 (see xorg.conf.d(5) for a reason) and other packages that do the
same thing systemd does.

-- 
|8]


-- 
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/87bolvt1f6.fsf@algernon.balabit

Re: RFC: OpenRC as Init System for Debian

[Gergely Nagy]

Steve McIntyre  writes:

> Jean-Christophe Dubacq wrote:
>>
>>If dpkg kept a copy of the original configuration file (to be retrieved
>>at all times), it would be easier to spot local changes.
>>I use etckeeper to do that, but it's a bit tiresome to isolate all local
>>changes (I have to save the diffs somewhere) (and a lost hope if you do
>>install etckeeper late in the workstation life). My  git-fu is probably
>>not good enough (I am probably looking for a "pristine" branch and a
>>rebased "local" branch used in production).
>
> You might be interested in a proposal at UDS this week:
>
> https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-dpkg-pristine-conffiles

So basically, we'd have a directory of files under /etc that are not
conffiles, and even made 0440. Amusing proposal.

Why not move them outside of /etc then, if they are not configuration
files, and should not be touched by the user?

(Yeah, sure, they can be moved out of /etc, but that doesn't stop the
original proposal being amusing, sorry.)

-- 
|8]


-- 
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/87fwb7t1vo.fsf@algernon.balabit

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/11/2012 06:39 PM, Gergely Nagy wrote:
> Long story short, I still don't see what the fuss is about.
>   
The fuss is about we're being told that there will be silent
overwriting of configuration files without being prompted about
changes, which potentially, will make it horrible to manage
upgrades in a decent way without knowing the corner cases.

On top of that, we're being told that this is the reason why
we should use this system, which is totally the inverse of
what we've been doing in Debian for years.

Thomas


-- 
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/4facf4fd.8000...@debian.org

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/11/2012 06:39 PM, Gergely Nagy wrote:
>In other words, it does *exactly* the same thing systemd is
>criticised for.
>   

Which doesn't mean that it's a good practice.

Thomas


-- 
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/4facf423.1090...@debian.org

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/11/2012 05:25 PM, Gergely Nagy wrote:
> And in etc-overrides-lib, config files still remain in /etc.
No.


-- 
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/4facf398.2010...@debian.org

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/11/2012 04:52 PM, Gergely Nagy wrote:
> Neither the FHS, nor the policy says anything about etc-overrides-lib as
> far as I can see. Neither pro or con. Do feel free to point me to the
> relevant section, would I be mistaken.
>   

Section 10.7.2 of dpm:

"Any configuration files created or used by your package must reside in
|/etc|."

The policy never talks about etc-overrides-lib configuration files, it
only tells
that all configuration files should go in /etc, and there's no
exception, and
it is also a "must".

Thomas


-- 
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/4facf2d8.5050...@debian.org

Re: RFC: OpenRC as Init System for Debian

[Gergely Nagy]

Stephan Seitz  writes:

> On Fri, May 11, 2012 at 10:52:25AM +0200, Gergely Nagy wrote:
>>Neither the FHS, nor the policy says anything about etc-overrides-lib as
>>far as I can see. Neither pro or con. Do feel free to point me to the
>>relevant section, would I be mistaken.
>
> To be honest, I still don’t really understand what the files in lib are:
>
> - Are they configuration examples with all possible settings and their
> default values and the application works fine without these files?
> Then they should be in /usr/share/doc/.

They are default settings for a particular service, and the application
does not work without them.

> - Or doesn’t the application start without these files? Then they are
> undoubtedly configuration files and according to FHS and Debian policy
> configuration files belong in /etc

It is indeed true, that these are settings the application does not work
without. So are many things under /usr/share, some of them similarly
configuration files (/usr/share/X11/xorg.conf.d/;
/usr/share/alsa/alsa.conf.d/ to name just two).

That a default happens to be in a file does not make it a configuration
file. A configuration file is something you *change* to alter a programs
behaviour.

With systemd, these files are under /etc. That the defaults are split
out into separate files is an implementation detail, nothing more. You
do *NOT* change the defaults. You change the settings.

>>The stuff in /lib are package defaults. Where the default is, in the
>>program, embedded, or in some file, doesn't really matter, it's an
>>implementation detail.
>
> It does matter. In the end it is the same situation as the firmware
> problem. For the hardware it doesn’t matter if the firmware is placed
> in an EEPROM on the hardware or loaded from the FS by the driver. But
> for Debian and its policy it is a difference.

Policy governs configuration. It never talks about default settings, it
does not mandate anywhere where and how defaults are to be set.

> So if you don’t want a default configuration from a file, because you
> don’t want to put a file in /etc, then you must compile the program
> with your default settings.

What happens if your defaults are open-ended? When you *can't* compile
them all in, because third party packages are able to extend the set of
default settings?

You can't compile in the defaults in that case. You could compile in the
subset shipped with the package, and you could make it so that third
party packages only use stuff in /etc, but that would needlessly
complicate matters for no real benefit.

>>worse - in some ways, even better - than some other existing practice
>>(the conf.d/ stuff I mentioned a few times elsewhere in this thread
>>already).
>
> I like conf.d. It makes things easier for e.g. rsyslog or sysctl.

They also suffer from the very same problem the defaults in /lib/systemd
do. Namely, if you did not change the default, and it changes under you,
your system can break without any kind of warning or notice, and very
little trace as to what went wrong.

-- 
|8]


--
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/87k40jt2l2.fsf@algernon.balabit

Re: RFC: OpenRC as Init System for Debian

[Gergely Nagy]

m...@linux.it (Marco d'Itri) writes:

> On May 11, Gergely Nagy  wrote:
>
>> And in etc-overrides-lib, config files still remain in /etc. Its just
>> the defaults that live elsewhere. That the defaults are files, and are
>> under /lib, is an implementation detail, similarly how gconf defaults
>> live under /usr/share/gconf/defaults.
> This is not similar to how gconf works, because gconf allows you to only 
> set the directives you need in the new file, while udev and systemd 
> require copying the whole file from /lib.

But by the wikipedia definition, the gconf defaults are config files
too. My point was to make it clear that blindly following that
definition might not lead to desirable results.

But, a few more examples of config files, or snippets from directories
different than /etc:

 * /usr/share/X11/xorg.conf.d/: I would especially like to quote these
   lines from the 50-synaptics.conf file from there:

   ,
   | # DO NOT EDIT THIS FILE, your distribution will likely overwrite
   | # it when updating. Copy (and rename) this file into
   | # /etc/X11/xorg.conf.d first.
   `

   While said file also says it is an example, looking at
   xorg.conf.d(5), it suggests that X11 will behave somewhat similar to
   systemd, and search for override-able config snippets in directories
   outside of /etc. According to the manpage:

"When the same information is supplied in more than one way, the
highest precedence mechanism is used."

   In other words, it does *exactly* the same thing systemd is
   criticised for.

 * /usr/share/alsa/alsa.conf.d/: Files herein will be processed by
   alsa-lib, according to the README. They are obviously config file
   snippets, and as such, if following the wikipedia definition, should
   be in /etc.

   I assume - though, haven't checked - that files in /etc can override
   these settings.

I could probably find more, but just two off the top of my /usr/share
seemed enough for now.

It seems to me that etc-overrides-non-etc is already existing practice,
if X11 and ALSA use it too, among others. In light of this, systemd is
no different. It just has more defaults in files under /lib.

Long story short, I still don't see what the fuss is about.

-- 
|8]


-- 
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/87obpvt313.fsf@algernon.balabit

Re: RFC: OpenRC as Init System for Debian

[Steve McIntyre]

Jean-Christophe Dubacq wrote:
>
>If dpkg kept a copy of the original configuration file (to be retrieved
>at all times), it would be easier to spot local changes.
>I use etckeeper to do that, but it's a bit tiresome to isolate all local
>changes (I have to save the diffs somewhere) (and a lost hope if you do
>install etckeeper late in the workstation life). My  git-fu is probably
>not good enough (I am probably looking for a "pristine" branch and a
>rebased "local" branch used in production).

You might be interested in a proposal at UDS this week:

https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-dpkg-pristine-conffiles

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane


-- 
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/e1ssnta-0007af...@mail.einval.com

Re: RFC: OpenRC as Init System for Debian

[Gergely Nagy]

Stephan Seitz  writes:

> On Fri, May 11, 2012 at 11:25:10AM +0200, Gergely Nagy wrote:
>>Are you happy with dropping a snippet into a conf.d/ directory, and your
>>software breaking on an upgrade without notice? Because that can happen
>>even now, with software that uses only /etc, and /etc alone for their
>>configuration, without any kind of default anywhere else.
>
> Yes, because I know that something is wrong when it breaks. This is
> better than the software is working but not anymore as you expect.

You do realize that the only difference between the two cases is that
when the default happens to be in /etc, you get a "Configuration file
updated" thing scroll by?

Other than that, things break exactly the same way, and you will have no
more information, and the one you have is of little use, as it happily
overwrote the unmodified default, so you'll have to hunt down the former
version anyway, to see the difference.

-- 
|8]


-- 
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/87vck3t483.fsf@algernon.balabit

Re: RFC: OpenRC as Init System for Debian

[Stephan Seitz]

On Fri, May 11, 2012 at 12:07:55PM +0200, Jean-Christophe Dubacq wrote:

BTW, for standard workstations, there is less and less need to change
things in /etc. My current quota is 1346 files in /etc for about 30 of
them with local changes. This is quite a bad signal/noise ratio.


Well, a standard workstation has many configuration changes I would say, 
but these changes are all user settings for their WM/DM or application 
configuration like pidgin or audacious that reside in /home/.


But if you don’t configure files in /etc, why is it a problem if you have 
many files in /etc?


Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


signature.asc
Description: Digital signature

Re: RFC: OpenRC as Init System for Debian

[Jean-Christophe Dubacq]

On 11/05/2012 08:47, Vincent Bernat wrote:
> OoO  Pendant le  journal  télévisé du  jeudi  10 mai  2012, vers  20:29,
> Jean-Christophe Dubacq  disait :
> 
>> I do not know about trivially merging changes in the etc-overrides-lib
>> model, but in the current model, I am presented with the dpkg prompt
>> about conffiles for some programs where I added (or changed) only one
>> line (off the top of my head: only the servers list in roundcube, for
>> example), and dpkg does not propose to merge the two files: I am either
>> stuck with keeping my old file, taking the new, or using a shell. All
>> these things are interactive and prevent unattended upgrades without
>> disruption of services.
> 
> roundcube uses  ucf for its  main configuration file and  therefore, you
> should have a prompt with possibility to merge.
Never got it. But I can quote other (courier, for example).
Even /etc/default/locale was "updated" (only to include a bunch of
comments). Is it really necessary ?

BTW, for standard workstations, there is less and less need to change
things in /etc. My current quota is 1346 files in /etc for about 30 of
them with local changes. This is quite a bad signal/noise ratio.

If dpkg kept a copy of the original configuration file (to be retrieved
at all times), it would be easier to spot local changes.
I use etckeeper to do that, but it's a bit tiresome to isolate all local
changes (I have to save the diffs somewhere) (and a lost hope if you do
install etckeeper late in the workstation life). My  git-fu is probably
not good enough (I am probably looking for a "pristine" branch and a
rebased "local" branch used in production).
-- 
Jean-Christophe Dubacq



signature.asc
Description: OpenPGP digital signature

Re: RFC: OpenRC as Init System for Debian

[Gergely Nagy]

Tollef Fog Heen  writes:

> ]] Gergely Nagy 
>
>> Tollef Fog Heen  writes:
>> 
>> > ]] Uoti Urpala 
>> >
>> > Hi,
>> >
>> >> Wrong: as mentioned in this thread before, one of the advantages of the
>> >> etc-overrides-lib model is the option of having a file in /etc that
>> >> first includes the one in /lib, then overrides just one particular
>> >> value. This allows handling more updates without needing manual changes,
>> >> as you can automatically pick up other updated values while keeping the
>> >> override, without needing to do 3-way merges.
>> >
>> > This doesn't always work, though.  For instance, for systemd, you'd have
>> > no way to get rid of an ExecStartPre line, since you can have multiple
>> > of them.  It's probably not that common, but it's a use case I want to
>> > support.
>> 
>> In that case, the including file can be changed (by the admin) to be a
>> separate file, that does not include, and get the usual conffile
>> conflict dpkg prompt.
>
> How would that work?
>
> I have /lib/systemd/system/foo.service and want to change something in
> it, I then create /etc/systemd/system/foo.service with a copy of the
> /lib one plus whatever changes I want.
>
> The version in /lib is then updated.  How is the admin notified?

NEWS.Debian, like with any significant default change.

Other than that, the best I can think of is keeping track of what
version of the package a default changed in, and triggering something
from preinst, when upgrading from a version that is older than the
change.

This however, requires a lot of manual work, might aswell shovel the
whole thing from under /lib to /etc then, but then we still didn't solve
the problem: suppose there is a unit file that supports starting
multiple instances, by way of symlinking. I start to use this feature,
I change nothing, just symlink files around. At some point, this feature
gets removed, my upgrade succeeds, but my instances won't start anymore,
and the best notification I have is something that scrolled by that a
conffile was upgraded.

In this case, we have a succesful upgrade resulting in a broken system,
because a default changed, and the user was not adequately notified.

Which gets us back to NEWS.Debian being the best solution. There simply
are cases where no automatism can be clever enough.

-- 
|8]


-- 
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/877gwjujxr.fsf@algernon.balabit

Re: RFC: OpenRC as Init System for Debian

[Stephan Seitz]

On Fri, May 11, 2012 at 11:25:10AM +0200, Gergely Nagy wrote:

Are you happy with dropping a snippet into a conf.d/ directory, and your
software breaking on an upgrade without notice? Because that can happen
even now, with software that uses only /etc, and /etc alone for their
configuration, without any kind of default anywhere else.


Yes, because I know that something is wrong when it breaks. This is 
better than the software is working but not anymore as you expect.


Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: RFC: OpenRC as Init System for Debian

[Stephan Seitz]

On Fri, May 11, 2012 at 10:52:25AM +0200, Gergely Nagy wrote:

Neither the FHS, nor the policy says anything about etc-overrides-lib as
far as I can see. Neither pro or con. Do feel free to point me to the
relevant section, would I be mistaken.


To be honest, I still don’t really understand what the files in lib are:

- Are they configuration examples with all possible settings and their 
  default values and the application works fine without these files? Then 
  they should be in /usr/share/doc/.
- Or doesn’t the application start without these files? Then they are 
  undoubtedly configuration files and according to FHS and Debian policy 
  configuration files belong in /etc



The stuff in /lib are package defaults. Where the default is, in the
program, embedded, or in some file, doesn't really matter, it's an
implementation detail.


It does matter. In the end it is the same situation as the firmware 
problem. For the hardware it doesn’t matter if the firmware is placed in 
an EEPROM on the hardware or loaded from the FS by the driver. But for 
Debian and its policy it is a difference.
So if you don’t want a default configuration from a file, because you 
don’t want to put a file in /etc, then you must compile the program with 
your default settings.



worse - in some ways, even better - than some other existing practice
(the conf.d/ stuff I mentioned a few times elsewhere in this thread
already).


I like conf.d. It makes things easier for e.g. rsyslog or sysctl.

Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: RFC: OpenRC as Init System for Debian

[Marco d'Itri]

On May 11, Gergely Nagy  wrote:

> And in etc-overrides-lib, config files still remain in /etc. Its just
> the defaults that live elsewhere. That the defaults are files, and are
> under /lib, is an implementation detail, similarly how gconf defaults
> live under /usr/share/gconf/defaults.
This is not similar to how gconf works, because gconf allows you to only 
set the directives you need in the new file, while udev and systemd 
require copying the whole file from /lib.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: RFC: OpenRC as Init System for Debian

[Gergely Nagy]

Thomas Goirand  writes:

> From: http://en.wikipedia.org/wiki/Configuration_file
>
> "In computing, configuration files, or config files configure the initial
> settings for some computer programs. They are used for user applications,
> server processes and operating system settings."
>
> The fact that these files are in /lib and shouldn't be touched by the admin
> doesn't make them less configuration files. They still match the above
> definition from Wikipedia.

Can I point you to /usr/share/glib-2.0/schemas/,
/usr/share/gconf/defaults and similar?

These are by the above definition, configuration files. Yet they are not
under /etc. They are used to load the initial configuration of software,
and can be overridden elsewhere (funny thing is, the gconf defaults can
be overridden with stuff in /var/lib/gconf/debian.* - even the overides
are outside of /etc!).

Can we fix these first, where not even the overrides are in /etc, let
alone the defaults? Please?

>> Just because something isn't supported currently in our tools doesn't
>> make it impossible to support it.
>
> The very reason why our tools don't support it, is because *we don't
> want it*.
> It's designed like this on purpose, and we are happy with the way things are
> right now.

Are you happy with dropping a snippet into a conf.d/ directory, and your
software breaking on an upgrade without notice? Because that can happen
even now, with software that uses only /etc, and /etc alone for their
configuration, without any kind of default anywhere else.

> Why can't you implement something like amavis, grub2, or apache are doing?
> Especially Amavis, where the default config is a conffile, but you can
> override
> what you need by using a higher number in the file name.
>
> It works well, it is integrated with Debian and the way things work...

It certainly does not work all that well. We came to live with it over
the years, is all.

>> And debian-policy isn't set in stone.
>> Otherwise it wouldn't have last been revised in February 2012 :)
>>   
>
> The debian-policy maybe, but the FHS, and config files in /etc *is* a very
> strong policy that you will not change in Debian, and for very valid
> reasons already described in this thread.

And in etc-overrides-lib, config files still remain in /etc. Its just
the defaults that live elsewhere. That the defaults are files, and are
under /lib, is an implementation detail, similarly how gconf defaults
live under /usr/share/gconf/defaults.

FHS and Policy are obeyed.

-- 
|8]


-- 
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/87bolvul1l.fsf@algernon.balabit

Re: RFC: OpenRC as Init System for Debian

[Tollef Fog Heen]

]] Gergely Nagy 

> Tollef Fog Heen  writes:
> 
> > ]] Uoti Urpala 
> >
> > Hi,
> >
> >> Wrong: as mentioned in this thread before, one of the advantages of the
> >> etc-overrides-lib model is the option of having a file in /etc that
> >> first includes the one in /lib, then overrides just one particular
> >> value. This allows handling more updates without needing manual changes,
> >> as you can automatically pick up other updated values while keeping the
> >> override, without needing to do 3-way merges.
> >
> > This doesn't always work, though.  For instance, for systemd, you'd have
> > no way to get rid of an ExecStartPre line, since you can have multiple
> > of them.  It's probably not that common, but it's a use case I want to
> > support.
> 
> In that case, the including file can be changed (by the admin) to be a
> separate file, that does not include, and get the usual conffile
> conflict dpkg prompt.

How would that work?

I have /lib/systemd/system/foo.service and want to change something in
it, I then create /etc/systemd/system/foo.service with a copy of the
/lib one plus whatever changes I want.

The version in /lib is then updated.  How is the admin notified?

(This is the problem I want to fix with some yet unwritten tool.)

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


-- 
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/87k40jnjmv@qurzaw.varnish-software.com

Re: RFC: OpenRC as Init System for Debian

[Gergely Nagy]

Philip Hands  writes:

> On Thu, 10 May 2012 21:30:56 +0300, Uoti Urpala  
> wrote:
>> Marco d'Itri wrote:
>> > On May 10, Bjørn Mork  wrote:
>> > 
>> > > Agree.  Copying a large set of default policies into /etc just because
>> > > they *can* be overridden is not user friendly.  And it does not make the
>> > > defaults any more configuration either. It just hides important local
>> > > changes and makes it difficult both for the user and the application
>> > > itself to distinguish between defaults and configuration overrides.
>> 
>> > Wrong:
>> 
>> You're not addressing what he said about the generally desirable /etc
>> semantics at all, only talking about what current Debian tools would do
>> without modifications. Do you have a reason to oppose beyond "this would
>> need some tool changes"?
>
> Yes -- it scatters configuration state outside /etc (thus hiding it from
> etckeeper and sysadmins alike), it makes the packages surprising to
> people familiar with Debian but not familiar with the package (Hint: we
> have a _lot_ of packages -- nobody is familiar with all of
> them. Requiring people to become familiar with all the packages before
> they can safely do an upgrade is part of what explains the number of
> rotting RedHat systems I see than nobody is brave enough to upgrade).

I'll turn this around: how do you handle cases where the defaults of
packages like apt, exim or syslogd change? Where the defaults are
embedded in the executable.

You don't. That systemd has the defaults in files under /lib is an
implementation detail. It's no different than any other default other
software comes with, except that this one is easier to see and notice
when it changes: it's possible to craft a trigger that'd fire in those
cases.

It's not possible to do that for cases where the default is hidden,
which is the case for the vast majority of software. Yet, I do not see
anyone jumping on those, and demanding they move *all* their defaults to
/etc.

>> >  since you have to copy the whole file to override it,
>> 
>> Wrong: as mentioned in this thread before, one of the advantages of the
>> etc-overrides-lib model is the option of having a file in /etc that
>> first includes the one in /lib, then overrides just one particular
>> value. This allows handling more updates without needing manual changes,
>> as you can automatically pick up other updated values while keeping the
>> override, without needing to do 3-way merges.
>
> This is the real problem with the etc-overrides-lib approach.  For a
> sysadmin to know what to expect from a particular set of configuration
> files they need to be intimately familiar with the package in question,
> and why the change was made.  Does the package allow partial overrides
> with includes or otherwise?  Is the existence of an empty file deeply
> significant (think the udev persistent net thing).  Did some default
> appear in lib that needs to be carried into etc? etc. etc.

The same could be said of various conf.d/-style hacks that plague the
archive. Do snippets override the things they change, or do they get
merged? One must be familiar with the particular program to figure it
out.

This problem exists in every piece of software that can be configured,
and does not use a single monolithic configuration file.

> The traditional Debian approach to /etc is largely self documenting, to
> the extent that one can generally walk into a site cold and (having
> established that they have decent backups) cheerfully do an upgrade on
> their Debian servers without anything breaking (I do this regularly).

I'm afraid my experience disagrees, see above: the conf.d/-style hacks
vary between packages, and there is *no* common ground. Some override
settings completely, some get merged, it largely depends not only on the
package in question, but in the setting aswell: even within a package,
some settings get merged, some get overwritten.

Sometimes it is even an error to try and override parts of the main
configuration within a snippet - and you can't tell that only by looking
at the files. You have to know the software in question, and how its
configuration works.

etc-over-lib is no different to existing practice. The only difference
is where the defaults live, nothing else.

> The sources of potential breakage are highlighted by the packaging
> system, at which point you can read up on any package that needs
> attention with which you're not already familiar, while ignoring the
> ones that upgrade cleanly.

Like I said elsewhere in the thread: conf.d/-style snippets. They're
widely used, show the same problems. etc-over-lib is no worse.

> Having exceptions to that is deeply unhelpful, and the more exceptions
> we accumulate the less maintainable and upgradable Debian becomes.

etc-over-lib is no exception. It's configuration in /etc, that overrides
or changes default. Like *every* other piece of configuration that is in
/etc. Where the default is, doesn't matter.

We *never* get notification w

Re: RFC: OpenRC as Init System for Debian

[Gergely Nagy]

Tollef Fog Heen  writes:

> ]] Uoti Urpala 
>
> Hi,
>
>> Wrong: as mentioned in this thread before, one of the advantages of the
>> etc-overrides-lib model is the option of having a file in /etc that
>> first includes the one in /lib, then overrides just one particular
>> value. This allows handling more updates without needing manual changes,
>> as you can automatically pick up other updated values while keeping the
>> override, without needing to do 3-way merges.
>
> This doesn't always work, though.  For instance, for systemd, you'd have
> no way to get rid of an ExecStartPre line, since you can have multiple
> of them.  It's probably not that common, but it's a use case I want to
> support.

In that case, the including file can be changed (by the admin) to be a
separate file, that does not include, and get the usual conffile
conflict dpkg prompt.

-- 
|8]


-- 
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/87sjf7umhf.fsf@algernon.balabit

Re: RFC: OpenRC as Init System for Debian

[Gergely Nagy]

Thomas Goirand  writes:

> On 05/11/2012 12:53 AM, Uoti Urpala wrote:
>> The reason why most old applications do not follow that approach (at
>> least not yet) is pretty obvious: their authors never considered it.
>> etc-overrides-lib semantics have only become a seriously considered
>> alternative fairly recently.
>>   
> No.
>
> The reason is that we have FHS and the policy, so that packages
> *have* to behave the same way, and for very valid reasons which have
> been well described in this thread.

Neither the FHS, nor the policy says anything about etc-overrides-lib as
far as I can see. Neither pro or con. Do feel free to point me to the
relevant section, would I be mistaken.

The stuff in /lib are package defaults. Where the default is, in the
program, embedded, or in some file, doesn't really matter, it's an
implementation detail.

Overrides (ie, configuration) *is* in /etc, as mandated by policy.

> You have absolutely everyone (this includes very experienced DDs)
> against your idea of changing a well established Debian policy, well
> written in the debian policy manual. Please stop. It's going nowhere.

Erm, no. It's not written in the debian policy for a start, and not
everyone agrees that etc-overrides-lib is a bad idea. I for one think
it's a good idea in selected cases (systemd being one such), and no
worse - in some ways, even better - than some other existing practice
(the conf.d/ stuff I mentioned a few times elsewhere in this thread
already).

-- 
|8]


-- 
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/87wr4jumk6.fsf@algernon.balabit

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/11/2012 04:04 AM, David Weinehall wrote:
> On Fri, May 11, 2012 at 02:44:45AM +0800, Thomas Goirand wrote:
>   
>> On 05/10/2012 04:52 AM, Steve McIntyre wrote:
>> 
>>> No, really - please *do* do this. The fact that a lot of the software
>>> coming out of RedHat development seems to be designed solely for their
>>> use, including working around the missing/broken features of RPM, is
>>> seriously annoying. Configuration belongs in /etc, we know this. We
>>> have a well-designed and implemented set of tools in Debian based on
>>> that standard.
>>>   
>>>   
>> I agree 100% with the above.
>>
>> On 05/10/2012 05:22 AM, Uoti Urpala wrote:
>> 
>>> Josh Triplett provided multiple technical reasons why etc-overrides-lib
>>> is preferable. The ONLY technical reason you gave to prefer traditional
>>> conffiles was that there already is a "set of tools" for that in Debian.
>>>   
>>>   
>> No, it's because this way, I am warned by the package manager of a change
>> on the default file, and I can merge by hand when I see it. Otherwise, you
>> are silently changing the default, and potentially, I will miss the new
>> options.
>>
>> Besides this, configuration files in /etc is written in the stones of
>> our bible^Wpolicy-manual.
>> 
> Has anyone argued for having the configuration files anywhere else?
> It's all in the semantics of course, but to me, the configuration files
> are the files that the administrator changes to change a configuration.
> The files that go in /lib are the defaults.  If the admin wants to
> override something they do so in /etc, just like before.
>   

From: http://en.wikipedia.org/wiki/Configuration_file

"In computing, configuration files, or config files configure the initial
settings for some computer programs. They are used for user applications,
server processes and operating system settings."

The fact that these files are in /lib and shouldn't be touched by the admin
doesn't make them less configuration files. They still match the above
definition from Wikipedia.

> If the old file in /lib isn't equal to the new file being installed to
> /lib, and there's a user supplied file in /etc rather than just the
> default (which would only include the version in lib), then prompt the
> user.  If the user is running a non-interactive upgrade, fire off an
> e-mail or something.  For any major changes to the /lib files (stuff
> that are likely to trigger user actions), NEWS.Debian should of course,
> as usual, contain a heads up.
>   

No need to explain again, again and again the same thing. We did understand
what your point is, but still, we don't agree with you and Uoti. Move on.

> Just because something isn't supported currently in our tools doesn't
> make it impossible to support it.

The very reason why our tools don't support it, is because *we don't
want it*.
It's designed like this on purpose, and we are happy with the way things are
right now.

Why can't you implement something like amavis, grub2, or apache are doing?
Especially Amavis, where the default config is a conffile, but you can
override
what you need by using a higher number in the file name.

It works well, it is integrated with Debian and the way things work...

> And debian-policy isn't set in stone.
> Otherwise it wouldn't have last been revised in February 2012 :)
>   

The debian-policy maybe, but the FHS, and config files in /etc *is* a very
strong policy that you will not change in Debian, and for very valid
reasons already described in this thread.

Thomas


-- 
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/4facd03a@debian.org

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/11/2012 12:53 AM, Uoti Urpala wrote:
> The reason why most old applications do not follow that approach (at
> least not yet) is pretty obvious: their authors never considered it.
> etc-overrides-lib semantics have only become a seriously considered
> alternative fairly recently.
>   
No.

The reason is that we have FHS and the policy, so that packages
*have* to behave the same way, and for very valid reasons which have
been well described in this thread.

You have absolutely everyone (this includes very experienced DDs)
against your idea of changing a well established Debian policy, well
written in the debian policy manual. Please stop. It's going nowhere.

Thomas


-- 
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/4faccc7d.3010...@debian.org

Re: RFC: OpenRC as Init System for Debian

[Philip Hands]

On Thu, 10 May 2012 21:30:56 +0300, Uoti Urpala  wrote:
> Marco d'Itri wrote:
> > On May 10, Bjørn Mork  wrote:
> > 
> > > Agree.  Copying a large set of default policies into /etc just because
> > > they *can* be overridden is not user friendly.  And it does not make the
> > > defaults any more configuration either. It just hides important local
> > > changes and makes it difficult both for the user and the application
> > > itself to distinguish between defaults and configuration overrides.
> 
> > Wrong:
> 
> You're not addressing what he said about the generally desirable /etc
> semantics at all, only talking about what current Debian tools would do
> without modifications. Do you have a reason to oppose beyond "this would
> need some tool changes"?

Yes -- it scatters configuration state outside /etc (thus hiding it from
etckeeper and sysadmins alike), it makes the packages surprising to
people familiar with Debian but not familiar with the package (Hint: we
have a _lot_ of packages -- nobody is familiar with all of
them. Requiring people to become familiar with all the packages before
they can safely do an upgrade is part of what explains the number of
rotting RedHat systems I see than nobody is brave enough to upgrade).

> >  since you have to copy the whole file to override it,
> 
> Wrong: as mentioned in this thread before, one of the advantages of the
> etc-overrides-lib model is the option of having a file in /etc that
> first includes the one in /lib, then overrides just one particular
> value. This allows handling more updates without needing manual changes,
> as you can automatically pick up other updated values while keeping the
> override, without needing to do 3-way merges.

This is the real problem with the etc-overrides-lib approach.  For a
sysadmin to know what to expect from a particular set of configuration
files they need to be intimately familiar with the package in question,
and why the change was made.  Does the package allow partial overrides
with includes or otherwise?  Is the existence of an empty file deeply
significant (think the udev persistent net thing).  Did some default
appear in lib that needs to be carried into etc? etc. etc.

The traditional Debian approach to /etc is largely self documenting, to
the extent that one can generally walk into a site cold and (having
established that they have decent backups) cheerfully do an upgrade on
their Debian servers without anything breaking (I do this regularly).

The sources of potential breakage are highlighted by the packaging
system, at which point you can read up on any package that needs
attention with which you're not already familiar, while ignoring the
ones that upgrade cleanly.

Having exceptions to that is deeply unhelpful, and the more exceptions
we accumulate the less maintainable and upgradable Debian becomes.

Your assert that etc-overrides-lib is technically superior -- I and many
others dispute that, but even if it were true, using that as a
justification is equivalent to pointing out that driving on the left is
safer[1] so Norway should make arrangements to allow visitors from the
UK to drive on the left while the rest of the country continues on the
right.  When it's pointed out that that's a disastrous idea you respond
by saying that all we need to do is fit some clever (as yet unbuilt)
collision avoidance system to all the roads.

> > Obviously this is not a problem for Red Hat since they do not support 
> > upgrades between major releases.
> 
> Why would this cause problems for Debian, except at most needing some
> changes to tools to better support this case? Or do you think
> implementing that would be hard?

Are you volunteering to do that?

If not then stop making assertions that simply require someone else to
do a load of work to pander to your unusual tastes.  If you are
volunteering, then that's somewhat better (although I would prefer
that we simply fix the packages to behave themselves in a proper Debian
way instead).

Cheers, Phil.

[1] see: 
https://en.wikipedia.org/wiki/Right-_and_left-hand_traffic#Safety_factors
  I believe Japan also did tests -- I don't really care if you disagree,
  just swap Left/Right and UK/Norway throughout the example and relax.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND


pgp9a7nnyxdyw.pgp
Description: PGP signature

Re: RFC: OpenRC as Init System for Debian

[Marco d'Itri]

On May 11, Nikolaus Rath  wrote:

> > Wrong: since you have to copy the whole file to override it, and files 
> > in /lib have no conffiles handling, after an upgrade you will not know 
> > what was changed by you and what was changed upstream.
> I think everyone here agrees with that. The interesting case is when
> files in /etc/ can either explicitly include the /lib file, or
> implicitly override the /lib settings.
I do not know about any package which work this way, but there is any 
then the problem is not different from packages which support multiple 
configuration file fragments in /etc, ship the default configuration 
in /etc and allow it to be modified by other configuration fragments in 
/etc (e.g. Apache).

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: RFC: OpenRC as Init System for Debian

[Vincent Bernat]

OoO  Pendant le  journal  télévisé du  jeudi  10 mai  2012, vers  20:29,
Jean-Christophe Dubacq  disait :

> I do not know about trivially merging changes in the etc-overrides-lib
> model, but in the current model, I am presented with the dpkg prompt
> about conffiles for some programs where I added (or changed) only one
> line (off the top of my head: only the servers list in roundcube, for
> example), and dpkg does not propose to merge the two files: I am either
> stuck with keeping my old file, taking the new, or using a shell. All
> these things are interactive and prevent unattended upgrades without
> disruption of services.

roundcube uses  ucf for its  main configuration file and  therefore, you
should have a prompt with possibility to merge.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

printk(KERN_WARNING "%s: Short circuit detected on the lobe\n",
dev->name);
2.4.0-test2 /usr/src/linux/drivers/net/tokenring/lanstreamer.c


pgputTalXJ2N9.pgp
Description: PGP signature

Re: RFC: OpenRC as Init System for Debian

[Tollef Fog Heen]

]] Uoti Urpala 

Hi,

> Wrong: as mentioned in this thread before, one of the advantages of the
> etc-overrides-lib model is the option of having a file in /etc that
> first includes the one in /lib, then overrides just one particular
> value. This allows handling more updates without needing manual changes,
> as you can automatically pick up other updated values while keeping the
> override, without needing to do 3-way merges.

This doesn't always work, though.  For instance, for systemd, you'd have
no way to get rid of an ExecStartPre line, since you can have multiple
of them.  It's probably not that common, but it's a use case I want to
support.

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


-- 
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/87vck3ns91@qurzaw.varnish-software.com

Re: etc-overrides-non-etc configuration file model [Re: RFC: OpenRC as Init System for Debian]

[Gergely Nagy]

Don Armstrong  writes:

> On Thu, 10 May 2012, Gergely Nagy wrote:
>> FWIW, /etc/default/* and /etc/$package/conf.d/* and similar already
>> do something *very* close to what etc-overrides-non-etc does. To the
>> point that changing a file under /etc/default, or adding a snippet
>> to conf.d/ can break just as well when the underlying default
>> changes as if that upstream happened to be outside of /etc.
>
> That's true. I suspect that much of conf.d/* and default/* are a
> consequence of the lack of easy 3-way merge support in dpkg. But
> that's kind of an orthogonal issue.

I don't think that is so. It's also there to allow other packages to
drop snippets there. Modifying another package's conffile would be
against the policy, so conf.d/-style snippets are the obvious solution.

Nothing to do with the lack of merge in this case. Even if dpkg gains
fabulous merge support that never fails, ever, conf.d/ will still be
used because we need the ability to add snippets from unrelated
packages.

>> Except it's easier to follow, since the default is never modified
>> by the admin, while if it's in /etc too, like in plenty of cases in
>> the archive, both can change, and we end up with even scarier
>> situations that can't be resolved sanely.
>
> I'm unable to follow. In the etc-overrides-non-etc case, we would be
> increasing the number of cases where we had copies in /etc and in
> non-etc.
>
> If things were just in /etc, they wouldn't be in non-etc, and you'd
> only have one copy in all cases.

True, if the non-etc stuff were simply copied, we'd have a single
copy. With all the disadvantages that brings, like not being able to
override the default from another package, as that would mean we have to
modify a configuration file.

In the case of systemd, you need to be able to override the default from
another, unrelated package. At least for things like the syslog
service.

At the moment, systemd has /lib/systemd/system/syslog.service, which
starts the journal. If I want to override that, I need to override the
syslog.service, which is done by placing a file in
/etc/systemd/system/syslog.service (whether a symlink, or a file,
doesn't matter; the syslog daemons in debian place a symlink).

If we didn't have etc-overrides-lib, how would you do this? How would
you make it able to override a single service, from another package?
Play dpkg-divert tricks? Or use conf.d/-style stuff?

The latter suffers from the same issue etc-overrides-non-etc suffers
from, the former makes it much harder for admins to override services,
and I don't like the idea of dpkg-divert'ing config files all over the
place either..

-- 
|8]


-- 
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/873977s1lq@luthien.mhp

Re: RFC: OpenRC as Init System for Debian

[Ben Hutchings]

On Thu, May 10, 2012 at 09:56:57PM +0100, Ben Hutchings wrote:
> On Thu, May 10, 2012 at 10:55:06AM -0700, Don Armstrong wrote:
> > On Thu, 10 May 2012, Uoti Urpala wrote:
> > > You're pretty much just saying that dpkg and helpers like ucf have
> > > implemented better functionality than rpm. I don't see how that's
> > > relevant to the discussion.
> > 
> > The reason why it is relevant is because in the etc-overrides-lib
> > model you are unable to trivially merge local changes with upstream or
> > packaging changes unless you add additional logic in the postinst to
> > handle etc-overrides-lib. Having configuration files in /etc and using
> > ucf or similar enables you to deal with this problem easily.
>  
> In the etc-overrides-lib model, program defaults and local
> configuration are effectively being merged every time the program
> starts.
[...]

Apparently I was mistaken and that's not what's usually implemented.
So this really does look like a workaround for stupid package
managers.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20120511010208.gg4...@decadent.org.uk

Re: RFC: OpenRC as Init System for Debian

[Nikolaus Rath]

m...@linux.it (Marco d'Itri) writes:
> On May 10, Bjørn Mork  wrote:
>
>> Agree.  Copying a large set of default policies into /etc just because
>> they *can* be overridden is not user friendly.  And it does not make the
>> defaults any more configuration either. It just hides important local
>> changes and makes it difficult both for the user and the application
>> itself to distinguish between defaults and configuration overrides.
>
> Wrong: since you have to copy the whole file to override it, and files 
> in /lib have no conffiles handling, after an upgrade you will not know 
> what was changed by you and what was changed upstream.

I think everyone here agrees with that. The interesting case is when
files in /etc/ can either explicitly include the /lib file, or
implicitly override the /lib settings.

It's not clear to me why such a system would be inferior to the current
debian practice.


Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-- 
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/87ipg3ioga@vostro.rath.org

Re: RFC: OpenRC as Init System for Debian

[George Danchev]

On Friday 11 May 2012 00:01:14 Uoti Urpala wrote:
--cut--
> > You need to at least start reading some man-pages (a good start would be
> > ucf(1), ucfr(1), ucfq(1), debconf-devel(7)) before keep jamming
> > suggestion like "improvements to be able to alert the user about
> > changes". This is already there, and has been there for a long time, as
> > also mentioned before.
> 
> I was talking about the etc-overrides-lib case; did you misunderstand
> that? Do those tools already have functionality which could be used for
> that case as is? If they do, I don't think it has been mentioned.

You can even do without any special tools for the applications following etc-
overrides-lib case, since at the end it all boils down to shipping the new 
default configuration file in /lib, and warn them about potential updates. 
There 
shouldn't be any merges involved, since this is the whole point of directory 
separation.

Postinst's 'configure' stage:

* communicate a stock (default) configuration file in /lib
diff /usr/share/doc/foo/foo.conf   /lib/foo.conf (or cksum them)
warn the user if the default (stock) configuration file has changed, send mail.
cp  /usr/share/doc/foo/foo.conf /lib/foo.conf

* optionally handle locally modified /etc/foo.conf... we should leave it alone,
and not mess up with it, since this is a local admin setttings overriding 
/lib/foo.conf as a whole or including it and overriding certain values only, 
but anyway a simple call to ucf for completeness:
ucf /usr/share/doc/foo/foo.conf  /etc/foo.conf
ucfr foo /etc/foo.conf

likewise, postrm, as shown in the man page.

Applications using more than one configuration file of effectively the *same 
type 
and purpose* (since there applications with several configuration files, 
grouped 
on different purposes) on startup would also cause the very same burden to the 
admin mentally exesicing this very same process and guessing which was set 
where and what overrides what. Not entirely pretty.

-- 
pub 4096R/0E4BD0AB 


-- 
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/201205110212.30503.danc...@spnet.net

Re: RFC: OpenRC as Init System for Debian

[Uoti Urpala]

Don Armstrong wrote:
> On Thu, 10 May 2012, Ben Hutchings wrote:
> > In the etc-overrides-lib model, program defaults and local
> > configuration are effectively being merged every time the program
> > starts.

This seems to assume that the program would always read both. systemd
unit files don't work this way; rather, if the file exists in /etc, then
only that version is read. However, you can use ".include" in the file
to read the default version and then override only parts. So you can
choose which semantics you want for each file you modify.


> This is only the case if the configuration files are fine grained
> enough that overrides to a configuration file wouldn't also need to
> incorporate upstream/packaging changes. In such a case,
> etc-overrides-non-etc makes perfect sense, and you wouldn't normally
> distribute a configuration file at all (or if you did, it'd just
> contain commented, current default values for commonly altered
> values).

I don't see why you'd equate it being reasonable to override just a few
values and there being no need for a distro configuration file at all.
Why would it be rare for a program to need distro configuration but have
some things the user would want to override independently?

> In cases where the configuration files are not (or co-mingled with
> application logic), then etc-overrides-lib is the same as running dpkg
> with --force-conf-old and having the configuration files in /etc.

That's assuming you don't improve the tools; etc-overrides-lib does not
intrinsically imply that. And of course you'd still have the other
advantages which would not be "the same".



-- 
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/1336689772.2227.158.camel@glyph.nonexistent.invalid

Re: etc-overrides-non-etc configuration file model [Re: RFC: OpenRC as Init System for Debian]

[Don Armstrong]

On Thu, 10 May 2012, Gergely Nagy wrote:
> FWIW, /etc/default/* and /etc/$package/conf.d/* and similar already
> do something *very* close to what etc-overrides-non-etc does. To the
> point that changing a file under /etc/default, or adding a snippet
> to conf.d/ can break just as well when the underlying default
> changes as if that upstream happened to be outside of /etc.

That's true. I suspect that much of conf.d/* and default/* are a
consequence of the lack of easy 3-way merge support in dpkg. But
that's kind of an orthogonal issue.

> Except it's easier to follow, since the default is never modified
> by the admin, while if it's in /etc too, like in plenty of cases in
> the archive, both can change, and we end up with even scarier
> situations that can't be resolved sanely.

I'm unable to follow. In the etc-overrides-non-etc case, we would be
increasing the number of cases where we had copies in /etc and in
non-etc.

If things were just in /etc, they wouldn't be in non-etc, and you'd
only have one copy in all cases.


Don Armstrong

-- 
a friend will help you move
a best friend will help you move bodies
but if you have to move your best friend's body
you're on your own
 -- a softer world #242
http://www.asofterworld.com/index.php?id=242

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20120510220412.gg3...@rzlab.ucr.edu

Re: RFC: OpenRC as Init System for Debian

[Don Armstrong]

On Thu, 10 May 2012, Ben Hutchings wrote:
> In the etc-overrides-lib model, program defaults and local
> configuration are effectively being merged every time the program
> starts.

This is only the case if the configuration files are fine grained
enough that overrides to a configuration file wouldn't also need to
incorporate upstream/packaging changes. In such a case,
etc-overrides-non-etc makes perfect sense, and you wouldn't normally
distribute a configuration file at all (or if you did, it'd just
contain commented, current default values for commonly altered
values).

In cases where the configuration files are not (or co-mingled with
application logic), then etc-overrides-lib is the same as running dpkg
with --force-conf-old and having the configuration files in /etc.

> Maybe users ought to be able to request notification when the
> defaults change. But isn't that true regardless of whether those
> defaults are written in the configuration file format or as part of
> the program itself?

Sure. I personally think it'd be nice to know if the defaults changed
too when I'd altered them. But doing that is difficult when the
defaults aren't already specified in a configuration file. Handling
configuration files as configuration files isn't that difficult.
 

Don Armstrong

-- 
Physics is like sex. Sure, it may give some practical results, but
that's not why we do it.
 -- Richard Feynman

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20120510215207.gf3...@rzlab.ucr.edu

Re: RFC: OpenRC as Init System for Debian

[Marco d'Itri]

On May 10, Jean-Christophe Dubacq  wrote:

> There are cases where file in /etc overrides only the directives present
> in /etc and not the rest. I prefer this way.
Fine, but they are not the cases which we are discussing.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: RFC: OpenRC as Init System for Debian

[Uoti Urpala]

George Danchev wrote:
> On Thursday 10 May 2012 21:46:41 Uoti Urpala wrote:
> > I don't see how the following would make this comparison with rpm relevant.
> 
> It was a comparison of the packaging system facilities to handle upgrades of 
> the configuration files of the applications. This was initially started by 
> you 
> as a misguided comparison between etc-overrides-lib (apples) vs. dpkg 
> conffiles 
> (oranges). Basically you're mixing up packaging system facilities to handle

No, I didn't mix those up like that. I think you're referring to my
comment about Josh Triplett providing technical reasons to prefer using
etc-overrides-lib semantics, but Steve McIntyre's reply only mentioning
existing "set of tools" as a counterargument (which was silly given his
rpm comments). That was comparing the quality of their arguments, not
comparing etc-overrides-lib model vs dpkg functionality.

I didn't initially parse the "comparison" in your original post that
way, because it doesn't seem like a plausible way to read my original
post.


> > Yes, you do need some tool improvements to be able to alert the user
> > about changes. This has been mentioned before. I don't think this would
> 
> You need to at least start reading some man-pages (a good start would be 
> ucf(1), ucfr(1), ucfq(1), debconf-devel(7)) before keep jamming suggestion 
> like "improvements to be able to alert the user about changes". This is 
> already there, and has been there for a long time, as also mentioned before.

I was talking about the etc-overrides-lib case; did you misunderstand
that? Do those tools already have functionality which could be used for
that case as is? If they do, I don't think it has been mentioned.


> > And as also mentioned before, the include option should reduce the
> > number of cases where you need to do 3-way merging.
> 
> You don't seem to understand that style of reading of configuration files of 
> the 
> applications is in the realm of the applications themselves and packaging 
> systems facilities which help handling upgrades of these application 
> configuration files can not frivolously add "include" or any other convenient 
> option directives you are suggesting to these application configuration files.

Of course I do understand that include directives require application
support. I don't know where you got the idea that such directives would
be added by any automatic packaging helper; this is about how user
modifies configuration (use include+override rather than copy+modify).



-- 
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/1336683674.2227.138.camel@glyph.nonexistent.invalid

Re: RFC: OpenRC as Init System for Debian

[gregor herrmann]

On Thu, 10 May 2012 20:29:05 +0200, Jean-Christophe Dubacq wrote:

> in the current model, I am presented with the dpkg prompt
> about conffiles for some programs where I added (or changed) only one
> line (off the top of my head: only the servers list in roundcube, for
> example), and dpkg does not propose to merge the two files: I am either
> stuck with keeping my old file, taking the new, or using a shell. 

Right, and I agree that's annoying.

Which means that our handling of conffiles has room for improvement,
and using Config::Model would be a way to do it.

Cheers,
gregor
 
-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Paul McCartney: Say Say Say


signature.asc
Description: Digital signature

Re: RFC: OpenRC as Init System for Debian

[Ben Hutchings]

On Thu, May 10, 2012 at 10:55:06AM -0700, Don Armstrong wrote:
> On Thu, 10 May 2012, Uoti Urpala wrote:
> > You're pretty much just saying that dpkg and helpers like ucf have
> > implemented better functionality than rpm. I don't see how that's
> > relevant to the discussion.
> 
> The reason why it is relevant is because in the etc-overrides-lib
> model you are unable to trivially merge local changes with upstream or
> packaging changes unless you add additional logic in the postinst to
> handle etc-overrides-lib. Having configuration files in /etc and using
> ucf or similar enables you to deal with this problem easily.
 
In the etc-overrides-lib model, program defaults and local
configuration are effectively being merged every time the program
starts.  I think that this is generally better than either the
dpkg-conffile model (ask the user to resolve) and the rpm-conffile
model (back up local version).

Maybe users ought to be able to request notification when the
defaults change.  But isn't that true regardless of whether those
defaults are written in the configuration file format or as part
of the program itself?

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20120510205657.gf4...@decadent.org.uk

Re: RFC: OpenRC as Init System for Debian

[David Weinehall]

On Fri, May 11, 2012 at 02:44:45AM +0800, Thomas Goirand wrote:
> On 05/10/2012 04:52 AM, Steve McIntyre wrote:
> > No, really - please *do* do this. The fact that a lot of the software
> > coming out of RedHat development seems to be designed solely for their
> > use, including working around the missing/broken features of RPM, is
> > seriously annoying. Configuration belongs in /etc, we know this. We
> > have a well-designed and implemented set of tools in Debian based on
> > that standard.
> >   
> I agree 100% with the above.
> 
> On 05/10/2012 05:22 AM, Uoti Urpala wrote:
> > Josh Triplett provided multiple technical reasons why etc-overrides-lib
> > is preferable. The ONLY technical reason you gave to prefer traditional
> > conffiles was that there already is a "set of tools" for that in Debian.
> >   
> No, it's because this way, I am warned by the package manager of a change
> on the default file, and I can merge by hand when I see it. Otherwise, you
> are silently changing the default, and potentially, I will miss the new
> options.
> 
> Besides this, configuration files in /etc is written in the stones of
> our bible^Wpolicy-manual.

Has anyone argued for having the configuration files anywhere else?
It's all in the semantics of course, but to me, the configuration files
are the files that the administrator changes to change a configuration.
The files that go in /lib are the defaults.  If the admin wants to
override something they do so in /etc, just like before.

If the old file in /lib isn't equal to the new file being installed to
/lib, and there's a user supplied file in /etc rather than just the
default (which would only include the version in lib), then prompt the
user.  If the user is running a non-interactive upgrade, fire off an
e-mail or something.  For any major changes to the /lib files (stuff
that are likely to trigger user actions), NEWS.Debian should of course,
as usual, contain a heads up.

Just because something isn't supported currently in our tools doesn't
make it impossible to support it.  And debian-policy isn't set in stone.
Otherwise it wouldn't have last been revised in February 2012 :)


Regards, David Weinehall
-- 
 /) David Weinehall  /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
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/20120510200439.gf10...@suiko.acc.umu.se

Re: RFC: OpenRC as Init System for Debian

[George Danchev]

On Thursday 10 May 2012 21:46:41 Uoti Urpala wrote:
> Don Armstrong wrote:
> > On Thu, 10 May 2012, Uoti Urpala wrote:
> > > You're pretty much just saying that dpkg and helpers like ucf have
> > > implemented better functionality than rpm. I don't see how that's
> > > relevant to the discussion.
> > 
> > The reason why it is relevant is because
> 
> I don't see how the following would make this comparison with rpm relevant.

It was a comparison of the packaging system facilities to handle upgrades of 
the configuration files of the applications. This was initially started by you 
as a misguided comparison between etc-overrides-lib (apples) vs. dpkg conffiles 
(oranges). Basically you're mixing up packaging system facilities to handle 
upgrades/transitions of application configuration files with the styles of 
applications reading their own configuration files.

> >  in the etc-overrides-lib
> > 
> > model you are unable to trivially merge local changes with upstream or
> > packaging changes unless you add additional logic in the postinst to
> > handle etc-overrides-lib. Having configuration files in /etc and using
> > ucf or similar enables you to deal with this problem easily.
> 
> Yes, you do need some tool improvements to be able to alert the user
> about changes. This has been mentioned before. I don't think this would

You need to at least start reading some man-pages (a good start would be 
ucf(1), ucfr(1), ucfq(1), debconf-devel(7)) before keep jamming suggestion 
like "improvements to be able to alert the user about changes". This is 
already there, and has been there for a long time, as also mentioned before. 
I'm pretty sure that merging techniques could be made even more smarter or, 
but "alerting the user" functionality has been there for a long time already.

> be hard to add though, and not overall harder than what is already
> implemented for traditional conffile handling; this is not a fundamental
> problem with the etc-overrides-lib model.
> 
> And as also mentioned before, the include option should reduce the
> number of cases where you need to do 3-way merging.

You don't seem to understand that style of reading of configuration files of 
the 
applications is in the realm of the applications themselves and packaging 
systems facilities which help handling upgrades of these application 
configuration files can not frivolously add "include" or any other convenient 
option directives you are suggesting to these application configuration files.

-- 
pub 4096R/0E4BD0AB 


-- 
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/201205102303.37863.danc...@spnet.net

Re: etc-overrides-non-etc configuration file model [Re: RFC: OpenRC as Init System for Debian]

[Gergely Nagy]

Don Armstrong  writes:

> On Thu, 10 May 2012, Uoti Urpala wrote:
>> Don Armstrong wrote: 
>> > The reason why it is relevant is because [...]
>> 
>> I don't see how the following would make this comparison with rpm
>> relevant.
>
> This is debian-devel, and we're talking about configuration file
> handling in Debian, which makes ucf and dpkg relevant.
>
>> > Having configuration files in /etc and using ucf or similar
>> > enables you to deal with this problem easily.
>> 
>> Yes, you do need some tool improvements to be able to alert the user
>> about changes.
>
> Right. So for every package which does this, you have to check to see
> whether a configuration file in /etc has had it's corresponding
> non-etc configuration file changed, and then offer to merge them
> together.

FWIW, /etc/default/* and /etc/$package/conf.d/* and similar already do
something *very* close to what etc-overrides-non-etc does. To the point
that changing a file under /etc/default, or adding a snippet to conf.d/
can break just as well when the underlying default changes as if that
upstream happened to be outside of /etc.

We do not handle that case either, and I don't see how the default being
outside of /etc would be any different. Except it's easier to follow,
since the default is never modified by the admin, while if it's in /etc
too, like in plenty of cases in the archive, both can change, and we end
up with even scarier situations that can't be resolved sanely.

> So there's basically no advantage to etc-overrides-non-etc unless one
> hasn't bothered to implement proper configuration file handling.

Then we already have a problem, because the conf.d/ and default stuff
suffer from the same problems, and they're used widely all over the
place.

-- 
|8]


-- 
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/87vck3de3i@luthien.mhp