On Tue, Jun 10, 2014 at 5:50 PM, Lennart Poettering <lenn...@poettering.net> wrote: > On Tue, 10.06.14 13:58, Mike Gilbert (flop...@gentoo.org) wrote: > >> > Symlinks should probably just be considered different type of file, that >> > have a contents and stuff. The contents is usually a file name, and >> > there's a size limit, but other than that it's just a magic kind of >> > file, where the symlink destination is the conents. That's how git >> > handles this, for example. >> > >> > I have the suspicion that this is really something to fix in your >> > package manager. It should learn to handle symlink upgrades the same way >> > as configuration file upgrades.... >> >> The problem with installing these symlinks as part of a package is >> that the user may have removed them from /etc/systemd using systemctl >> disable. The next time they install systemd, the package puts the >> symlinks right back. > > Again, that's exactly what happens for configuration files too if you > use automake: on "make install" they are replaced by the original, > upstream versions. Why is recreating the symlinks bad, if overriding the > config files isn't? >
People don't generally remove config files; they just make changes. On the other hand, removing the symlinks would be a very typical action due to the way systemctl disable works. There is some ambiguity as to what a missing symlink means: did the sysadmin remove it, or did it never exist in the first place? If systemctl disable would do something like create a symlink to /dev/null, that would be easier to detect. I suppose we should implement something like Debian's conffiles to protect file removals, but that's probably not going to be a very high priority given the small number of packages for which it really matters. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
