Subject: Re: Removal of Edited Config Files
To: NetBSD Packages Technical Discussion List <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 12/19/1998 14:25:23
[ On Fri, December 18, 1998 at 18:22:26 (-0800), Curt Sampson wrote: ]
> Subject: Removal of Edited Config Files
> I disagree. If I pkg_add bind8 and then edit /etc/named.conf, that's
> no longer the file that pkg_add added. It's now a file that contains
> unique (and possibly not replicated) information that I put on to
> the system. pkg_delete should not be deleting these things, because,
> unlike all of the other files deleted, there's no way for the
> package system to get that information back should you decide you
> made the wrong decision when deleting that package.
That's not a good argument (it's not so bad as to be a "lame" argument,
but it's not a good enough argument, especially since I've already
sufficiently addressed your concerns).
First off you should have backups so that you can recover lost
information, regardless of who's fingers are guilty of deleting it.
Same argument would apply if you deleted a package for which you no
longer had the original distribution archive [eg. a commercial package
that comes only on a CD that discover you've now lost, only after you've
already deleted every instance of it].
In any case your argument is moot on all fronts if pkg_delete simply
renames the to-be-deleted but modified files.
> Note that this is how the package system works right now; pkg_delete
> will not remove a file if the MD5 of it does not match the MD5 the
> file originally installed had.
I suppose the reason that I "forgot" about this is because I also have
issue with it. Pkg_delete should not refuse to delete modified files.
It should, by default, refuse to delete *packages* containing modified
Then if *any* file in the package has been modified pkg_delete will
simply complain and quit. The administrator must then decide either to
forcibly remove the entire package, or to choose to have any modified
files renamed (and perhaps chmod'ed to avoid leaving security bugs
available to malicious users) while all other files are deleted.
Greg A. Woods
+1 416 218-0098 VE3TCP <email@example.com> <robohack!woods>
Planix, Inc. <firstname.lastname@example.org>; Secrets of the Weird <email@example.com>