(proposal) new flag for pkg_delete

[David Taylor]

On Wed, 03 Sep 2003, Will Andrews wrote:

> On Wed, Sep 03, 2003 at 03:39:48PM +0100, David Taylor wrote:
> > It fails to mention that if -f is specified it will also delete any files
> > where the MD5 checksum is incorrect.  I have now been repeatedly bitten by
> > portupgrade wiping my configuration information because it specifies -f
> > (as it must, in order to remove packages which are still 'in use' by other
> > packages).
> 
> Wrong way to fix the problem.  Make the ports install sample
> config files and only add those to the plist, not the actual ones.
> 

As I stated in my previous reply, I am aware this is a real problem (which
I would also like to fix, in a more 'proper' way than the pkg_delete
patch), so I have another suggestion.

However, I beleive this suggestion has been made repeatedly before, but
noone has ever come to an agreement, mainly because noone has ever done
much to make it happen.

The suggestion is, to use a mergemaster style tool to handle port/pkg
config files.  Whilst we're at it, the base system mergmaster could
(optionally?) use the new system to.

The main features I could see as desirable would be:

	Package/port installed config files will not overwrite any files.

	Deinstalling packages/ports will not by default remove config data.

	Merging of changes from distributed config files against
	local versions.

I have an idea which appears to satisfy all of those goals, but
unfortunately uses RCS.  It may turn out it would be easier to use CVS.
I would prefer to use a non RCS/CVS tool, because they are fairly
'difficult' tools, and making users use them as part of the ports system
is not perhaps a great idea.  Hopefully the needs of the config system
would not tickle any bugs in RCS/CVS and can use other tools around the
rcs/cvs commands, to prevent users shooting themselves in the foot.

Enough babbling, the idea essentially is:

(Bad ASCII Art diagram 1: Example rcs 'tree' for a config file)
dist_1 -> dist_2 -> dist_3  -> dist_4
 1.1       1.2       1.3        1.4
 \           \         \
  \           \         \
   |           |         |
  user_1a   user_2a     user_3a
   1.1.1.1   1.2.1.1     1.3.1.1
   |           |
   |           |
  user_1b   user_2b
   1.1.1.2   1.2.1.2

Ports (using some tool [pkgcfg_install ?]) install new config files on to
the head branch (dist_* in the diagram).  Another user tool (pkgcfg_merge)
merges any differences, and checks in the user accepted version on to the
corresponding branch:

For dist_1 it would display the new file, and store the editted version
(if different) on the 1.1.1 branch.

For dist_2 it would display a 3 way diff style view of the changes between
dist_1 -> dist_2, merged into user_1b (the tip of the 1.1.1 branch).

The revision (or branch) number of the latest user revision would need to
be stored somewhere (probably in /var/db/pkg).

Thus, ports could add new config files to the rcs file without affecting
users, who could simply run 'pkgcfg_merge' to view diffs of what has
changed.  Upon deinstallation, nothing need happen -- although the config
file could be backed up in to the rcs file, then removed.  On
re-installation, a port could detect the existing config file, and check
that out.

The rcs file could be optionally removed on deinstallation, and a tool
would be able to allow their removal fairly easy.

If I could find a better way than RCS/CVS to do this, I would probably
starting hacking at it tomorrow some time.

Unless someone can see an obvious flaw in my grand scheme? :)

-- 
David Taylor
davidt at yadt.co.uk
"The future just ain't what it used to be"