Thanks both for your replies, I have responded to both below.
From: Olaf van der Spek <olafvds...@gmail.com>
Those people using a configuration management system like Puppet
won't get to see dpkg's nice output, and will have to merge the changes by
hand in their repos and push them out to all their machines.
Isn't that a limitation of Puppet?
It is a limitation I think of any/every configuration control system.
The point is that it's not a perfect improvement. Having conf bits in
more files means it's harder for a normal user to find/read/update all
bits.
That's true, but then in this case the user already has to find/read/update
the bits in the conf-available directory so one more split shouldn't come as a
surprise.
We do agree that (in principle) it would be nice to support stuff like
Puppet better.
So let's say we've got lighttpd.conf and platform.conf. Where would
the ipv6 include go? I'd say platform.conf.
Since you wanted to disable the ipv6 include, you'd have to modify
platform.conf and you'd have the same problem as you do now, right?
Not quite. Since enabling IPv6 support works the same on any distro, it
shouldn't go in the platform-specific section. I would say, as a rough guide,
anything you *must* change from the upstream lighttpd.conf to make it fit into
Debian (user/group, pidfile, etc.) would go into platform.conf, and anything
you change just to make it nicer (like IPv6 or the default module list) can go
into some other file. For example, I would only expect these options to be in
platform.conf:
server.upload-dirs = ( "/var/cache/lighttpd/uploads" )
server.errorlog = "/var/log/lighttpd/error.log"
server.pid-file = "/var/run/lighttpd.pid"
server.username = "www-data"
server.groupname = "www-data"
compress.cache-dir = "/var/cache/lighttpd/compress/"
From: Arno Töll <deb...@toell.net>
You always need to check major upgrades for changes and
incompatibilities anyway. In particular there is no guarantee your old
configuration file will work with the new daemon version.
With a new daemon version yes, but with a security update or similar where the
version is unchanged it may not be necessary. Say for example you had
accidentally set the lighttpd user to root and the default document-root to
"/". The web server would still work and when the mistake is realised the
platform.conf could be easily updated to correct the mistake, without
requiring any config merging.
I just hate splitted configuration files personally because I prefer one
single file where I can see all things I need to know at one sight.
Sometimes it makes sense to split files, e.g. for "actual configuration"
vs "site/vhost configuration" but most of the time settings spread
randomly throughout different files are hard to read, to understand and
to configure in my opinion.
That is a valid point, and unfortunately not one I can counter argue. If you
are editing by hand then yes, a single file is nice, but if you are "editing
by machine" then separate files are easier to handle. Perhaps, if you have a
large enough file, it will also be difficult to find the section you want. But
with nicely-named separate files, it can be made easy to locate the section
you are interested in.
I'm afraid, but we have no influence at all what other distributions
choose as configuration layout and/or which files they ship. Eventually
Suse (or whatever) still continues to ship a lighttpd.conf happily
specifying their own pidfile stuff there.
One more reason not to use Suse then, if they make it difficult :-) Also you
say you have no influence over other distros, but I don't think you give
yourself enough credit. There are many distributions that are based on Debian!
If you want to introduce such a change among all Linux distributions,
you better get upstream to split their configuration files out of the
box to make sure distributions will follow more likely.
This is an interesting idea, but upon closer investigation, probably not
practical. The upstream config file has defaults like storing the log files
next to the document-root, which the Debian package has overridden and changed
to /var/log. So in upstream, there would be no need to split that option out,
but in Debian there is because of the change. So I would argue that since you
are changing the option anyway, you may as well change it in a separate file :-)
Thanks again for being so willing to discuss this, you have given me plenty to
think about!
Cheers,
Adam.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
