From owner-freebsd-bugs@FreeBSD.ORG Fri Feb 4 19:02:04 2005 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6492716A4CE; Fri, 4 Feb 2005 19:02:04 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CD5E43D2D; Fri, 4 Feb 2005 19:02:04 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j14J4vRO010618; Fri, 4 Feb 2005 11:04:57 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j14J4vh5010617; Fri, 4 Feb 2005 11:04:57 -0800 Date: Fri, 4 Feb 2005 11:04:57 -0800 From: Brooks Davis To: Florent Thoumie Message-ID: <20050204190457.GB5389@odin.ac.hmc.edu> References: <200502032350.j13NoKLF045837@freefall.freebsd.org> <42039BAA.2070900@xbsd.org> <20050204183546.GA5389@odin.ac.hmc.edu> <4203C1D9.5090108@xbsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4203C1D9.5090108@xbsd.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-bugs@freebsd.org cc: FreeBSD-gnats-submit@freebsd.org cc: hq@freebsd.org Subject: Re: bin/77082: src/usr.sbin/pkg_install - Add 3 new macros to clean pkg-plist X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 19:02:04 -0000 On Fri, Feb 04, 2005 at 07:41:29PM +0100, Florent Thoumie wrote: > Brooks Davis wrote: > > >It seems like dirrmtry should take an optional message to emit if the > >event that the directory can not be delete. That way the user can be > >informed that the directory should be removed if they are really done > >using the port. > > I asked myself if I should put this feature in my patch and > I finally haven't because it required some extra-stuff > (handling optional arguments for @ commands is painful), and a > simple '@unexec [ -d ${PREFIX}/etc ] && echo ...' is easier I > guess. But that's no problem for me to include that if everybody > thinks it worth it. Given this workaround, it's probably not a high priority to add this. Hmm, what about a seperate @echoifexists or similar command? > >Have you thought about how to solve the boot strapping problems with > >pkg_install/pkg_delete? > > I have absolutely no idea what you're talking about, I started > looking at pkg_install source yesterday at night. Could you > give me some pointers about that ? The issue is that you need to find a way to keep users from installing packages they can't uninstall. If you add new commands and they are used in ports, users with older systems won't have the necessicary pkg_delete commands to make them work. The current system doens't even give a graceful way of detecting this condition both in the port and when the users installs a pkg from the -stable collections online. Longer term, we need some versioning in the plist and ports, but first we've got to solve the problem we're stuck with now. > >Our nominal pkg_install maintainer is MIA at the moment. > > Ok, actually I knew eik has been working on it, but I didn't > know who was the active maintainer now. Last I heard, eik was the one working it, but no one has heard from him in a while. He's been gone long enough that someone else could certaintly commit to pkg_install given public review. > I have thought of a new purge command, that would act like > dpkg --purge on Debian but AFAIK that would be impossible > since it would need persistent package records (that still > exists after a package has been removed as long as we have > some configuration files for this port in the tree). This would be a really cool feature. Off hand, you'd probably want to create another dirctory under /var/db to store these records. That would certaintly be allowed to support such a feature. -- Brooks