From owner-freebsd-ports@FreeBSD.ORG Tue Jan 20 11:02:27 2004 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 683) id 3D2C216A4CF; Tue, 20 Jan 2004 11:02:27 -0800 (PST) Date: Tue, 20 Jan 2004 11:02:27 -0800 From: Eivind Eklund To: Marius Strobl Message-ID: <20040120190227.GJ94636@FreeBSD.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040120194157.K93730@newtrinity.zeist.de> User-Agent: Mutt/1.4.1i cc: ports@FreeBSD.org cc: Kris Kennaway cc: Joe Marcus Clarke 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:02:27 -0000 On Tue, Jan 20, 2004 at 07:41:57PM +0100, Marius Strobl wrote: > 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. > 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. I would do it by chmod. (I habitually build as a user, too - but I don't think this patch will make much of a difference.) > 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. Because targets are supposed to be able to run separately. It could possibly be done by a bunch of .if make(target) statements to only delay when a suitable delay point is, but the patches added so far are about as complex as I would dare on a single pass, anyway. Eivind.