Date: Wed, 3 Sep 2003 19:29:25 +0100 From: David Taylor <davidt@yadt.co.uk> To: freebsd-arch@freebsd.org Subject: Re: (proposal) new flag for pkg_delete Message-ID: <20030903182925.GA79913@gattaca.yadt.co.uk> In-Reply-To: <20030903144734.GZ47671@procyon.firepipe.net> References: <20030903143948.GA61515@gattaca.yadt.co.uk> <20030903144734.GZ47671@procyon.firepipe.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@yadt.co.uk "The future just ain't what it used to be"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030903182925.GA79913>