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

2012-05-11 Thread Gergely Nagy
Don Armstrong d...@debian.org 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: etc-overrides-non-etc configuration file model [Re: RFC: OpenRC as Init System for Debian]

2012-05-10 Thread Gergely Nagy
Don Armstrong d...@debian.org 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



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

2012-05-10 Thread 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