Sven Joachim <svenj...@gmx.de> writes: > On 2012-05-09 14:01 +0200, Gergely Nagy wrote: > >> Philipp Kern <pk...@debian.org> writes: >> >>> On Wed, May 09, 2012 at 10:39:38AM +0200, Gergely Nagy wrote: >>>> > 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. >>> >>> Technical nit: No, unit files aren't. AIUI a package would ship its >>> unit file in /lib/systemd/system (i.e. RedHat-style). If you need to >>> override it, you're of course free to copy it to /etc/systemd/system and >>> make the necessary adjustments. You will not, however, get a conffile >>> update prompt when the system file changes (e.g. to update your own >>> local copy to incorporate the fix). >> >> Nothing prevents us from shipping the symlinks in the debian package >> (which some packages do, like rsyslog). The symlinks can be marked as >> conffiles (which rsyslog does not do) and then modifications will be >> preserved. > > FWIW, marking symlinks as conffiles is not to be recommended currently, > since dpkg does not handle them the way most people would expect[1,2].
I know. But in case the symlink points to a non-conffile, even with the disadvantages, it's better to mark one as conffile than to overwrite user settings. At least until a tool exists that can handle the situation better, marking these symlinks as conffiles is the best I can think of. The only disadvantage I found so far, is that during upgrades, the user won't be notified, and a .dpkg-new file will be created if the symlink was modified in any way. That does not cause any ill side-effects, I believe, and the biggest issue is that the user is not notified. If the file from /lib was copied and modified, it can be diffed with .dpkg-new. If the symlink was altered, and the target changed too (due to another package upgrading), that's a problem, but nothing would save us from that, except putting the unit files under /etc to begin with. -- |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/87ipg5xwn2.fsf@algernon.balabit
