From owner-freebsd-ports@FreeBSD.ORG Wed Aug 24 10:08:07 2011 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A30951065673 for ; Wed, 24 Aug 2011 10:08:07 +0000 (UTC) (envelope-from conrads@cox.net) Received: from eastrmfepo202.cox.net (eastrmfepo202.cox.net [68.230.241.217]) by mx1.freebsd.org (Postfix) with ESMTP id 4AA168FC08 for ; Wed, 24 Aug 2011 10:08:07 +0000 (UTC) Received: from eastrmimpo03.cox.net ([68.1.16.126]) by eastrmfepo202.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20110824100759.BWUC32466.eastrmfepo202.cox.net@eastrmimpo03.cox.net> for ; Wed, 24 Aug 2011 06:07:59 -0400 Received: from serene.no-ip.org ([98.164.83.25]) by eastrmimpo03.cox.net with bizsmtp id QA7x1h00H0YnB6A02A7y4M; Wed, 24 Aug 2011 06:07:58 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A02020B.4E54CD7E.0104,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=1.1 cv=mwl0/2xM3ubHJTXa6l4kGPt5l4r2ytuQtfJUKIGJKFg= c=1 sm=1 a=VRQvp7ExAqQA:10 a=G8Uczd0VNMoA:10 a=kj9zAlcOel0A:10 a=2vO5UZG1h46htWAnE/rx2g==:17 a=WF2pI21SAAAA:8 a=kviXuzpPAAAA:8 a=08cF-CzAHCuxezaLSAoA:9 a=6SmBS-JgzqgpYbKH790A:7 a=CjuIK1q_8ugA:10 a=MHmzl5aOqcYA:10 a=4vB-4DCPJfMA:10 a=2vO5UZG1h46htWAnE/rx2g==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Received: from cox.net (localhost [127.0.0.1]) by serene.no-ip.org (8.14.5/8.14.5) with ESMTP id p7OA7q6w026641 for ; Wed, 24 Aug 2011 05:07:52 -0500 (CDT) (envelope-from conrads@cox.net) Date: Wed, 24 Aug 2011 05:07:47 -0500 From: "Conrad J. Sabatier" To: freebsd-ports@freebsd.org Message-ID: <20110824050747.292efe91@cox.net> In-Reply-To: <4E54B5EF.7090709@infracaninophile.co.uk> References: <4E53BB67.1040805@bally-wulff.de> <4E54A1F4.50200@bally-wulff.de> <4E54B5EF.7090709@infracaninophile.co.uk> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Request for Comments] Add a "AFFECT" relationship between ports X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 10:08:07 -0000 On Wed, 24 Aug 2011 09:27:27 +0100 Matthew Seaman wrote: > On 24/08/2011 08:02, Luca Pizzamiglio wrote: > > I'd explain the behavior with an example: nvidia-driver port. > > During the installation process, this port moves the official Xorg > > openGL installing the NVidia ones. > > Removing nvidia-driver port, the old official libraries are > > restored. > > nvidia-driver is pretty much a special case in the ports. I think it > (and its slave ports) are the only ports that do anything like that. > > Your idea is interesting however. Do you have any other examples > where this would apply? Luca and I were discussing just that before he submitted this proposal. I have to admit that, other than the nvidia-driver port, nothing else of a similar nature leaps to mind, but that doesn't necessarily mean that such a beast isn't already lurking somewhere in the ports tree, just waiting to be discovered/reported, nor does it preclude the possibility of a similar situation arising in the future. I don't know if the amount of effort needed to implement such a feature can actually be justified at this point. Luca and I didn't discuss any actual implementation details, and to be honest, I'm not even sure where one would begin. But it does seem to me that there should be *some* sort of standardized mechanism for dealing with cases like this, rather than leaving it up to the user to improvise his own workaround. Even with a well-posted advisory notice ("This port requires special handling. Here's what you have to do..."), one can't escape the conclusion that this is one area where the ports collection simply breaks down, or at least, breaks away from the usual convention of supporting fully automated handling of the low-level details of building a package. To require this sort of hands-on intervention on the user's part just seems to be completely contrary to the entire design/philosophy. The ports collection really is quite a marvel of ingenuity in dealing with a lot of very complicated issues in a very methodical and organized fashion. It bothers me greatly to think that there's this one weakness in an otherwise brilliant design. Just my $.02 worth. :-) -- Conrad J. Sabatier conrads@cox.net