Uoti Urpala <uoti.urp...@pp1.inet.fi> writes: > Gergely Nagy wrote: >> Uoti Urpala <uoti.urp...@pp1.inet.fi> writes: >> > Not having the files in /etc by default does have technical advantages. >> > It's easier to see what is local non-default configuration. Original >> > default file is always available in a known location (and very easy to >> > revert to, temporarily for testing or permanently). You can use >> > ".include /lib/defaultsfile" then override some value, which in most >> > cases is more maintainable than the 3-way merging required by >> > "traditional" conffiles. >> >> Perhaps then the packages that right now ship symlinks to /lib/systemd/ >> stuff could be changed to ship a file that consists of a single .include >> line? > > Note that the general case is not just about existing symlinks, but also > cases were /etc contains no file unless you want to override default > configuration, and the program then reads the default from /lib > instead.
That is an easy case: the package shouldn't ship neither a symlink, nor any other override. Though, there's one more case where a symlink/override is required: when you're dealing with a package that implements a special service, such as a syslogd: those need to register themselves as syslog.service. >> That way, they can be treated as normal conffiles without any of the >> disadvantages of a symlink. diffing and whatnot will magically work, and >> we'd still have the benefit of having /lib/systemd/ separate from the >> /etc/systemd/ overrides. > > I don't see how this would avoid the need to improve dpkg diffing or add > another tool. It would only highlight the case where the /lib thing moved. Nothing else - but that's still an improvement. And if one uses include & overrides instead of copy & change, then bugfixes made to the original are more likely to get used. Pretty much how a snippet in /etc/default works - the init script including it can change, and you get no notice at all if you didn't change it. You only get notified when the /etc/default/$foo file changes too. For important stuff, there's NEWS.Debian still, and then we don't need any special tool. -- |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/87aa1hdobz....@luthien.mhp