Bug#322348: /etc/init.d/apache script wasn't removed by postrm

["A. Costa" <agcosta@gis.net>]

On 1 Nov 2005 09:07:37 -0000
"Pawel Wiecek" <coven@vmh.net> 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...