hey stephen, On Wed, May 04, 2005 at 11:38:38AM -0400, Stephen Gran wrote: > This is what /etc/$package is for. If the templates/plugins/whatever > are admin modifiable, then they should go under /etc/. Trying to hack > around dpkg wanting to overwrite files under /usr/share is only going to > cause a lot of work for little gain. ucf would be a lot of help for > these files, however. i initially stated this as well. i firmly believe that NOTHING in /usr/share/$package should be modifiable by the user. if a package provides any means of customizing it via editing files, those files should go in /etc/$package and either be aliased or symlinked if needs require. however, there are cases outside the scope of this, such as the bugzilla issue mentioned earlier, or in the case that someone wants to "rebrand" or modify an otherwise non-customizable app. > For this, I would suggest registering the file with ucf on first > install, and then there will be no false prompts (e.g., if ucf gets > called to track a merge, but doesn't know about the file, it will always > prompt by default) i think it would be an even worse idea to do ucf on the files within /usr/share/$package. my reasons for wanting a tool to do this outside of /usr/share/$package: - not in the spirit of the FHS. - outside of /usr == outside of policy. - keeping it out of policy makes the policy a hell of a lot simpler - any common infrastructure will be much simpler, and less prone to failure. - the "pristine" copies of the files are always available. - it eliminates the risk of the user making changes that are silently lost (in case something was missed by ucf, for example) - those who don't want this feature wouldn't need to worry about some bug in the feature destroying their install. now, all of this should be prefixed with the proviso that i don't think such a practice is the greatest idea ever. i think such a tool should be clearly stated as a last resort for situations where there aren't other alternatives. however, i'd argue that providing it in this manner (as opposed to any of the other alternatives brought up) gives a best possible result for everyone involved. sean ps - nice to see you on this list. --
Attachment:
signature.asc
Description: Digital signature