Date: Tue, 31 Jan 2006 15:55:20 +0300 From: Andrew Pantyukhin <infofarmer@gmail.com> To: Kris Kennaway <kris@obsecurity.org> Cc: FreeBSD Ports <ports@freebsd.org>, Pav Lucistnik <pav@freebsd.org> Subject: Re: pkg_delete and modified files Message-ID: <cb5206420601310455g555d22c5ic39440d46166f670@mail.gmail.com> In-Reply-To: <20060128215142.GA37639@xor.obsecurity.org> References: <cb5206420601281344q125a691cqfdf021012fb5afea@mail.gmail.com> <20060128215142.GA37639@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/29/06, Kris Kennaway <kris@obsecurity.org> wrote: > On Sun, Jan 29, 2006 at 12:44:50AM +0300, Andrew Pantyukhin wrote: > > Looking for a solution to the problem we stumbled upon, > > [which was keeping many modified files without the > > cmp trick described in the porter's handbook] > > I gave pkg_install/* sources a glance and now I'm > > thinking about a quick fix. The -f flag causes files to be > > deleted even in case of a checksum mismatch. In fact > > the -f flag is meant for something slightly else: > > > > Force removal of the package, even if a dependency > > is recorded or the deinstall or require script fails. > > > > So I'm thinking about another flag (like -F or a second > > -f) to control the behavior with modified files. I think that > > keeping them should be a default. I can't think of a > > thing that it will break, maybe you can. The cmp trick > > will still work. And it only takes a couple of lines to > > implement. > > We can't do this by default for all ports because a lot of ports > install files that are *supposed* to be modified by other ports > (e.g. gettext), so those files would never get removed. > > I think you'd need to have some more fine-grained method to control > this on a per-file basis. Btw, I'd like to draw your attention to the fact that pkg_delete does this by default (for all ports). It's the undocumented fact of the '-f' flag, which is used quite often (but not always) that causes the files to be deleted. We can't rely on that anyway, this will cause much breakage sooner or later.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cb5206420601310455g555d22c5ic39440d46166f670>