Re: Bug#135273: popularity-contest: overwrites a conffile without prior notice

[Manoj Srivastava <srivasta@debian.org>]

Hi,

        [Moving this over to debian-devel, and thus leaving in the context]

>>"Avery" == Avery Pennarun <apenwarr@nit.ca> writes:

 Avery> On Tue, Feb 26, 2002 at 10:53:58AM -0600, Manoj Srivastava wrote:
 >> I thought about that. However, ucf does not know when it is
 >> appropriate to use diff3, or which files to consider when it
 >> does. Providing all this information to ucf at invocation is just as
 >> hard as calling diff3 in the postinst yourself, and you have more
 >> conrtol, and are not restricted by whatever standard interface ucf
 >> shall have to impose. 

 Avery> As far as I understand (the man page explains many details,
 Avery> but I got lost looking for a basic explanation), when I do

 Avery> 	ucf /usr/share/avepkg/ave.conf /etc/ave.conf

 Avery> ucf will copy the file to /etc/ave.conf if it doesn't already
 Avery> exist.  It also keeps track of which version of
 Avery> /usr/share/avepkg/ave.conf it used, so it knows not to do
 Avery> anything special when the package is upgraded.

	It does so, however, by adding a single md5sums line to a hash
 file that it keeps. So the storage overhead of ucf is pretty minimal
 -- one single file,, and up to 6 backups.

 Avery> Because it's less automatic than dpkg's conffile management,
 Avery> we can also do clever things like generate an intermediate
 Avery> file based on the user's settings (/tmp/ave.conf.test or
 Avery> whatever) and ucf that one into /etc/ave.conf, and as long as
 Avery> the postinst auto-generates the same file each time, it won't
 Avery> have to prompt the user.

	Correct.

 Avery> Okay, good, that's already much better than before.

	Thanks ;-)

 Avery> ...

 Avery> Now here's the extra feature I would like:
 Avery> 	ucf --automerge /usr/share/avepkg/ave.conf /etc/ave.conf
	
 Avery> When given the --automerge option, ucf should work like this:
 Avery>  - ucf remembers the exact config file that was created
 Avery>    (copied from /usr/share) the first time it auto-generated
 Avery>    ave.conf.  Store this file in /var/state somewhere, perhaps.

	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).

	The Con is that this has the added benefit of allowing users
 to do a diff with the upstream file anytime they choose

 Avery>  - user edits config file in /etc
 Avery>  - user updates package, so the file in /usr/share changes
 Avery>  - postinst runs 'ucf --automerge /usr/share/avepkg/ave.conf /etc/ave.conf'
 Avery>  	(again)
 Avery>  - ucf detects that the file in /etc isn't the same as it was
 Avery>    last time; it still has the original in /var/state, the new
 Avery>    one in /usr/share, and the user's file in /etc.
 Avery>  - ucf attempts to auto-merge the changes between /var/state
 Avery>    and /usr/share  into the file in /etc.
   
 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.

 Avery> I think this would be very handy for a large number of
 Avery> packages, and doesn't need a very complicated API.  If the
 Avery> package wants to do something else, the non-automerge mode of
 Avery> ucf will still let them do it.

	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) 

 Avery> I realize that this sort of thing can be error prone, but
 Avery> implementing it differently in every single Debian package is
 Avery> much more error prone, I think :)

	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.

======================================================================
       Filesystem Hierarchy Standard                    April 12, 2000
       5.  The /var Hierarchy
       /var -- Variable data
       +-cache     Application cache data
       +-lib       Variable state information
       +-spool     Application spool data
      5.2  /var/cache : Application cache data

       /var/cache -- Cache directories
       +-<package> Package specific cache data

       /var/cache is intended for cached data from applications.  Such
       data is locally generated as a result of time-consuming I/O or
       calculation.  The application must be able to regenerate or
       restore the data.  Unlike /var/spool, the cached files can be
       deleted without data loss.  The data should remain valid
       between invocations of the application and rebooting the
       system.

       5.5  /var/lib : Variable state information
       /var/lib -- Variable state information
       +-<package> State data for packages and subsystems
       This hierarchy holds state information pertaining to an application or
       the system.  State information is data that programs modify while they
       run, and that pertains to one specific host.  Users should never need to
       modify files in /var/lib to configure a package's operation.

       5.11  /var/spool : Application spool data
       /var/spool contains data which is awaiting some kind of later
       processing.  Data in /var/spool represents work to be done in the future
       (by a program, user, or administrator); often data is deleted after it
       has been processed.

======================================================================
	
        I see that /var/cache data is supposed to be regeneratable,
 which these files shall not be. So, /var/cache is out too. Now these
 files are not going to be deleted after being worked upon, so
 /var/spool does not seem right either.

	/var/lib/ucf/files/ seems to be a winner.

	manoj
-- 
 Humorists always sit at the children's table. Woody Allen
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C