Re: Bug#135273: popularity-contest: overwrites a conffile without prior notice
On Wed, Feb 27, 2002 at 12:28:11PM -0600, Manoj Srivastava wrote:
> Hmm. The con side is that this increases storage requirements
> a lot -- one file per configuration file systemwide managed by
> ucf. We also have to be ready to deal with namespace management --
> /etc/foo/defaults and /etc/bar/defaults should not map to the same
> file name (use the full path name | tr / % or something).
Right. My /etc is only about 10 megs, though, and I personally would be
happy to sacrifice another 10-20 megs of my disk in order to keep extra
copies of files and avoid the annoyance. Maybe not everyone feels the same
way, though, and I can't think of a good way to make it optional.
As for namespaces, we could just keep a mirror of the tree:
/var/lib/ucf/etc/foo/defaults, for example. This keeps it from getting
crowded all into one directory.
> The Con is that this has the added benefit of allowing users
> to do a diff with the upstream file anytime they choose
I assume you mean pro. Yes.
> Avery> - Conflicts: ask user, no conflicts: don't ask user.
>
> Well, no. Nothing should be changed from under a user modified
> configuration file without asking. The automunged file may no longer
> be a valid file as far as the application is concerned.
I would like an option to just let it not ask me whenever possible, although
I can see why some people might not want that. For the most part, I'd
prefer to notice brokenness manually and fix it, rather than be prompted for
each and every probably-going-to-be-fine merge.
Note that apps using --automerge would presumably have config files that are
expected to automerge in a useful way (ie. not crazy xml structures, unless
we find a good xmldiff3 :)).
> Well, if we want to have people be able to alternate between
> using the automerge option and not in succeeding versions, we
> need to keep a copy of all configuration files. (aside: starting to
> use --automerge when we have no copy in /var/state also needs to be
> handled)
I think we can handle the two cases like this:
- switch from automerge to non-automerge: delete the old file in
/var/lib/ucf; never merge automatically.
- switch from non-automerge to automerge (ie. /var/lib/ucf/whatever doesn't
exist): ask whether to copy the package's version or keep the user's
old one, then, in _either_ case, store the package's version in
/var/lib/ucf as usual. (Of course, if the package's version is the
same as the existing file, don't ask.)
I think that'll be safe, or at least no less safe than the current dpkg.
And switching back and forth shouldn't happen very often anyway.
> If there is interest in this, I'll see what I can do to
> enhance ucf. Hmm. /var/state, /var/cache/, /var/lib/ or /var/spool?
> Oh, /var/state does not seem to be in the FHS shipped with policy.
You're right, it appears /var/lib/ucf seems to be the right place.
Have fun,
Avery
Reply to: