On Sun, Jan 03 2010, Russ Allbery wrote:
> Manoj Srivastava <sriva...@ieee.org> writes:
>> On Sun, Jan 03 2010, Russ Allbery wrote:
>
>>> I don't believe that listing symlinks as conffiles works properly at
>>> the moment. See #421344. It doesn't make any sense to list a
>>> directory as a conffile. I think that exhausts all the non-regular
>>> files that can be in a Debian package.
>
>> A conffile is, after all, a configuration file. As such, it
>> contains configuration data, and user changes to such data is what
>> policy is concerned about preserving. Merely the presence or absence of
>> a inode or a link does not rise to the level of "configuration data",
>> in my view. Why add restrictions on what people can do?
>
> I think a symlink created by the package in /etc should be handled like a
> conffile in the sense that if the sysadmin changes the symlink to point to
> a different path, that's a change that should be preserved. As I recall,
> that's the scenario that prompted Bug#421344 originally. Currently, I
> believe such changes are not preserved on package upgrade.
>
>> Now, if the target of the symlink is under /etc, then the target
>> is really the configuration file, if the target does not lie under
>> /etc, we have a policy violation.
>
> 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.
>>> Symlinks as conffiles should ideally work. I think it's just a bug in
>>> dpkg that they don't.
>
>> While it could be made to work, I am not sure I agree that the
>> result would require the same protection in policy.
>
>> I am willing to be persuaded otherwise on this.
>
> Well, I think all that Policy requires for configuration files that would
> be relevant to symlinks is:
>
> * If the administrator removes it, it stays removed on package upgrade.
>
> * If the administrator changes it, which in the case of a symlink just
> means pointing it to a different path, that change is either preserved
> or prompted about.
> Both of those seem feasible and reasonable to me. (Of course, someone
> would need to do the work, and I don't think it's the highest-priority
> dpkg development goal.)
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.
> I'm not sure what the implications of changing the symlink to be a real
> file or a directory would be. (I'm not sure what happens if an
> administrator changes a regular conffile to a directory.)
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.
manoj
--
There are bugs and then there are bugs. And then there are bugs. Karl
Lehenbauer
Manoj Srivastava <sriva...@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
