Date: Wed, 3 Sep 2003 15:14:28 -0400 From: The Anarcat <anarcat@anarcat.ath.cx> To: freebsd-arch@freebsd.org Subject: config files in packages (Re: (proposal) new flag for pkg_delete) Message-ID: <20030903191427.GE541@xtanbul> In-Reply-To: <20030903182925.GA79913@gattaca.yadt.co.uk> References: <20030903143948.GA61515@gattaca.yadt.co.uk> <20030903144734.GZ47671@procyon.firepipe.net> <20030903182925.GA79913@gattaca.yadt.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
(This is just moot since I have absolutely no time to implement this, but it's food for thought i have been digesting for a long time now) Debian adopted what I think is an elegant solution to this problem. The configuration files are marked as such in the package. When deinstalling, you must explicitely ask it if you want the configuration files to be removed. When upgrading or installing over, the package "knows" the old MD5 of the config files, so if they match (ie the config wasn't modified), they're overwritten. If the md5 don't match (ie the config was modified), the user is presented with an interface similar to that of mergemaster (minus the merge capabilities, unfortunatly). I think this scheme could be generalized to all the files in the package. What I would see for our pkg_tools is the following: 1- overwriting of unmodified files 2- merging of modified files (1) already works, provided that we don't use the -f flag to pkg_delete, since the old files simply get deleted. (2) would need a better integration between pkg_add and pkg_delete, because problem is right now, unless I'm mistaken, a package upgrade is made in 2 seperate process that don't really talk to each other: pkg_delete and pkg_add. The way I see it, ideally, pkg_add should be able to call pkg_delete on the old package. When files would be left behind, it would mean that they were modified outside the package system and that we need to merge. Anyways, pkg_add shouldn't overwrite already existing files. So the most basic solution to this whole problem would be to hack pkg_add to make it merge with existing non-binary files and ask in case of binary. Doing this would allow us to get out of the "default config" and "working config" scheme that is hard to maintain. When using such a scheme, if a major configuration parameter changes, you're SOL unless you diff against the your copy of the config. The pkg_add hack could take care of that. But then there's also the problem of make install in the ports. We would need a custom install target for configuration files that would check for existence before installing. This could actually be a little script that is called by pkg_add and do-install for certain files. Just my $CA 0,02... A.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030903191427.GE541>