On 1 Nov 2005 09:07:37 -0000 "Pawel Wiecek" <[EMAIL PROTECTED]> wrote:
> > Does the Debian distro's definition of a "config file" include > > executables? > > Debian definition of config file expressly includes everything in /etc. And > yes, startup script is definitely a config file, since system-specific > configuration can be set there. Thanks for the explanation. So it's expected that some users change their '/etc/init.d/' scripts and they don't want 'em removed unless they '-purge' 'em; result being that none of their tweaks and hacks are ever wiped out without permission. It sounds reasonable. So there's two kinds of users, those that change config scripts and those who don't. Hence bugs (or "bugs", depending on one's view) like this -- the naive users are surprised that config code still runs after its package is removed. Possible accommodation: have packages distinguish between config data and config scripts by some arbitrary flag. When a package is uninstalled (but not purged) it does a checksum test on any of its '/etc' config scripts, and if any were changed, it leaves them all intact, (since they might interact), perhaps with a helpful message to the user explaining this. Whereas if no config scripts were changed, then the user belongs to the no-change group, and the uninstaller deletes them all, as they contain no user data and serve no purpose. Note that this would be on a per-package basis, so that a user might want to change (and keep) the config scripts in package 'foo', but not those of package 'bar'. If it turns out that method would break too many useful things, then about all that I can see for it is to leave the code as is, but somehow improve the docs and prompts so that its behavior becomes familiar enough to seem less surprising. Or a third party helper install util (like 'localepurge') could be written for naive users who want to keep a removed package's config data, but not its config scripts. The util would work as described above, except it'd probably have to distinguish scripts from data on the fly. Or maybe somebody'll write a better 'apt' type program someday, with improved names and data structures... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
