> Josh Triplett, 2011-12-30 16:09+0100:
> > A de-facto standard has already emerged for how to ship the standard
> > configuration in /usr/lib and handle overrides,
>
> I do not think this is a de facto standard at all yet. What pieces of
> software use apply it? The length of that list should be compared to the
> order of magnitude of something like $(ls -1 /etc | wc -l) on a typical
> system before assuming that this has become the standard.
I didn't say that it had become as common as just having files in /etc;
I just suggested that programs which put their defaults outside of /etc
and allow overrides via /etc seem to follow a common approach which
makes them easy to find and override.
A quick check turned up the following software following the "/usr/lib
with /etc override" approach just on my own system:
- pm-utils
- PolicyKit
- ConsoleKit
- Parts of iceweasel
- Parts of Xorg
- systemd and its various helper components
- udev (modulo it currently using /lib rather than /usr/lib, but that
kind of thing started this whole thread in the first place)
The following packages have the same semantics, but use /usr/share
rather than /usr/lib, presumably because they don't consider their
default configurations architecture-specific:
- initramfs-tools
- TeX/LaTeX
- angband
- menu
- insserv
- defoma
- terminfo
- XKB
- calendar
My search also turned up a pile of other packages which *almost* manage
to follow this standard (default configuration in
/usr/{lib,share}/$package/ with overrides in /etc/$package/), but use
slight variations on naming between the files/directories in /usr and
the files/directories in /etc. Those kinds of inconsistencies really
ought to get fixed.
> The fact that a given piece of software is new or written by Lennart
> or whoever does not make its behaviour standard at all. The existence
> of a recommendation from IETF, LSB or XDG does, however.
I said "de-facto standard" for a reason; that means precisely the
opposite of standards produced by the organizations you mentioned.
- Josh Triplett
--
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/20111231000954.GA11680@leaf
