Manoj Srivastava <sriva...@ieee.org> writes: > On Sun, Jan 03 2010, Russ Allbery wrote:
>> Symlinks in /etc pointing to files not in /etc are used now, so I'm not >> sure they should be Policy violations. /etc/nologin is the canonical >> example. Depending on how and whether Debian adopts upstart, we may >> have other cases. > Hmm. The part that bothers me about this is that I can't just > say $EDITOR /etc/foo-that-is-a-symlink and expect it to work, unless > the symlink points to a file on a fs that is not mounted RO. But I > guess this is not a major obstacle. > I don't like configuration data not all being under /etc; s that > backing up /etc no longer saves a snapshot of my configuration. In the case of the possible use case for upstart, the target of the symlink is the entirety of the configuration in that case, so there's nothing lost by only backing up /etc. It's either a symlink pointing to the generic upstart code to do the right thing with an upstart job (separately installed in /etc/upstart.d or wherever), or it's a file implementing a more conventional init script. nologin is a weird special case, but I think the idea is that it's not persistent configuration anyway. If you're restoring the configuration of one box to another, chances are you don't want /etc/nologin anyway. > If this does not yet work, it does not really belong in policy > yet -- we should let the implementation happen and the design settle > down before standardizing the behaviour. Oh, agreed. My proposal for Policy would be to state, for the time being, that only regular files can be conffiles and that neither symlinks nor directories (the latter being somewhat obvious, but worth stating explicitly) can be conffiles. If at some point symlinks as conffiles are implemented in dpkg, we would then change Policy. Right now, if one declares a symlink as a conffile, bad things happen. > Umm, directories can't be conffiles, no? So not considering > directories, if symlinks can be conffiles, and regular files can be > conffiles, I think users should be allowed to change one conffile into > another. And the code must then handle that case. Yes, I think that's right. That could probably be handled in a way similar to the current handling of a deleted conffile. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
