From owner-freebsd-ports@FreeBSD.ORG Tue Jan 20 11:22:47 2004 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1E7316A4CE; Tue, 20 Jan 2004 11:22:47 -0800 (PST) Received: from newtrinity.zeist.de (newtrinity.zeist.de [217.24.217.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54EAE43D58; Tue, 20 Jan 2004 11:22:14 -0800 (PST) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (localhost [127.0.0.1]) i0KJLtsX016650; Tue, 20 Jan 2004 20:21:55 +0100 (CET) (envelope-from marius@newtrinity.zeist.de) Received: (from marius@localhost) by newtrinity.zeist.de (8.12.10/8.12.10/Submit) id i0KJLoVn016649; Tue, 20 Jan 2004 20:21:50 +0100 (CET) (envelope-from marius) Date: Tue, 20 Jan 2004 20:21:50 +0100 From: Marius Strobl To: Joe Marcus Clarke Message-ID: <20040120202150.L93730@newtrinity.zeist.de> References: <1074590694.85583.20.camel@shumai.marcuscom.com> <400D2939.5090203@fillmore-labs.com> <1074617147.757.16.camel@gyros> <20040120171315.GH94636@FreeBSD.org> <1074619795.757.43.camel@gyros> <20040120190234.A13333@newtrinity.zeist.de> <1074621917.757.61.camel@gyros> <20040120194157.K93730@newtrinity.zeist.de> <1074625391.757.86.camel@gyros> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1074625391.757.86.camel@gyros>; from marcus@FreeBSD.org on Tue, Jan 20, 2004 at 02:03:11PM -0500 X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.23.0.2; VDF 6.23.0.35 cc: ports@FreeBSD.org cc: Kris Kennaway cc: Eivind Eklund cc: Oliver Eikemeier Subject: Re: HEADS UP: New bsd.*.mk changes X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2004 19:22:47 -0000 On Tue, Jan 20, 2004 at 02:03:11PM -0500, Joe Marcus Clarke wrote: > On Tue, 2004-01-20 at 13:41, Marius Strobl wrote: > > On Tue, Jan 20, 2004 at 01:05:17PM -0500, Joe Marcus Clarke wrote: > > > On Tue, 2004-01-20 at 13:02, Marius Strobl wrote: > > > > On Tue, Jan 20, 2004 at 12:29:55PM -0500, Joe Marcus Clarke wrote: > > > > > > > > > > I agree. This approach seems the most flexible. As for not being able > > > > > to do non-root installs, this is a bogus argument as one could simply > > > > > override PORT_DBDIR as they would PKG_DBDIR (even with the original > > > > > patch). > > > > > > > > > > > > > I was taking about non-root builds, e.g. single ports checked out > > > > outside of PKGBASE to do maintenance work, not non-root installs. In > > > > an environment where non-root installs are done your argument is valid. > > > > Not being able to do non-root builds compilcates the job of maintainers. > > > > > > As I said, non-root builds could override PORT_DBDIR the same way you > > > could override PKG_DBDIR. You could point that to a directory to which > > > you could write. What am I missing? > > > > > > > In general I'd like to further on be able to build a port as non-root > > and install als root, with default PREFIX, PKG_DBDIR and PORT_DBDIR. > > Ah, I follow you. > > > I don't see how this currently should work, if I set PORT_DBDIR to a > > directory I can write to before I build the port as non-root it won't > > neither read an existing OPTIONSFILE in the default location nor write > > a possibly changed OPTIONSFILE to the new location. I could move around > > the OPTIONSFILE before and after installing the port but that's really > > messy. > > At a first glance I don't see a reason why creation of PORT_DBDIR if > > not already existing and writing of the OPTIONSFILE can't be done in > > e.g. the fake-pkg target or a new target that's executed directly > > before or after fake-pkg. > > This may work, but it would require some reworking of the existing > architecture, and, depending on patch complexity, may require another > test build on bento. Did you have something specific to review? > No. I will look at it when the issue regarding the default for the OPTIONSFILE and the layout of PORT_DBDIR, which currently is much more important, has settled.