From owner-freebsd-ports@FreeBSD.ORG Thu Apr 3 13:41:07 2003 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 6AB1037B401 for ; Thu, 3 Apr 2003 13:41:07 -0800 (PST) Received: from ints.mail.pike.ru (ints.mail.pike.ru [195.9.45.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2192F43FA3 for ; Thu, 3 Apr 2003 13:41:06 -0800 (PST) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 12243 invoked from network); 3 Apr 2003 21:57:37 -0000 Received: from babolo.ru (HELO cicuta.babolo.ru) (194.58.226.160) by ints.mail.pike.ru with SMTP; 3 Apr 2003 21:57:37 -0000 Received: (nullmailer pid 876 invoked by uid 136); Thu, 03 Apr 2003 21:43:44 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <20030403032202.A695@spadger.best.vwh.net> To: Andrew Sparrow Date: Fri, 4 Apr 2003 01:43:44 +0400 (MSD) From: "."@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1049406224.147843.875.nullmailer@cicuta.babolo.ru> cc: freebsd-ports@freebsd.org cc: Kris Kennaway Subject: Re: Setting make options permanently (WITHOUT_GNOME, etc) 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: Thu, 03 Apr 2003 21:41:07 -0000 > On Wed, Apr 02, 2003 at 05:43:02PM -0800, Kris Kennaway wrote: > > On Wed, Apr 02, 2003 at 10:18:45PM +0000, Andrew Sparrow wrote: > > > On Wed, Apr 02, 2003 at 12:15:30PM -0800, Kris Kennaway wrote: > > > > On Wed, Apr 02, 2003 at 12:14:19AM -0800, Andy Sparrow wrote: > > > > > > > > > For some bizarre and inexplicable (at least to me) reason, everyone who > > > > > bikesheds around Yet Another Way to provide persistant build options to > > > > > ports completely ignores this extremely convenient, pre-existing and > > > > > perfectly functional mechanism. > > > > > > > > One of the design features of the ports collection is that it can be > > > > used read-only, e.g. mounted read-only via NFS. > > > > > > I know thanks. I frequently update/install ports (and/or worlds, > > > for that matter) on my firewall that were built on a faster machine. > > > > > > Other than the fact it's a little difficult for the port you're > > > installing to create .install_done.${PORT} on a R/O FS, it seems to > > > work fine. > > > > That's what WRKDIRPREFIX is for. Of course, WRKDIR is not persistent > > because it is deleted whenever you do 'make clean'. > > > > > (and, IIRC, you may need to remove the .install_done file - from > > > the serving machine, naturally - otherwise make thinks it doesn't > > > need to do anything). > > > > > > > Makefile.local cannot be used there. > > > > > > I don't understand what you mean. The options in the file are used > > > to build the port. > > > > > > If those options are not applicable to the machine on which you > > > install it, then that's as doomed an act on the user's part as > > > setting the CPU architecture to P4 on the building machine (e.g. > > > in make.conf) and then installing the resulting binaries on a 486. > > > > > > Could you clarify your statement if I've misunderstood what you meant? > > > > I meant that for people using a RO ports tree, Makefile.local in the > > port directory is not an option. Given that this is a supported use > > of the ports collection, Makefile.local cannot be a general-purpose > > solution for storing local configuration state for the port. > > Ah, I see what you're driving at now. I'd never actually considered > using a R/O ports tree and building ports locally with WRKDIRPREFIX. > > Probably because my sole usage of a R/O ports tree (and I'd always > assumed, most peoples') is aimed at getting around two specific > problems: > > i) Lack of local disk space > ii) Lack of local grunt I do not understand ii) reason - lack of English knowledge and can't intuit, which sence of many possible in dictionary to use. But it seems to me, that my case not i) or ii) My reason is manageability. I have my server with /usr/ports, /usr/src, /usr/ports/distfiles and some else exported to a lot of nets I work for. All in good state for use when I or some admins need to use. But all that nets are not trusted enough to export rw, so exported ro only. Every host use its own PACKAGES=${TMPDIR} WRKDIRPREFIX=${TMPDIR} MAKEOBJDIRPREFIX?=${TMPDIR} But truth is that there is not only 2 classes of space - wide distributed constant sources (/usr/ports) and local temporary $WRKDIRPREFIX and $MAKEOBJDIRPREFIX. There is need for another class of space - local RO addidions to global RO sources. I use $LOCAL_PATCHDIR_PREFIX for local patches (PR ports/45200 refused by kris for false reason) for such class of space. It seems to me, that Makefile.local belongs to that class of space. This file tree can has its own repository, NFS servers for export it so on. It is shielded from ruin by cvsup because it is separate tree. (refuse list is long and depends on current state and source of $LOCAL_PATCHDIR_PREFIX) .. > Unless I'm missing something more fundamental (always possible), > this manner of usage doesn't seem too useful to me - although I > will grant that, for consistancy and managability, it is very nice > to use (e.g.) a CD of a ports tree snapshot and update all your > machines to/from the same vintage of everything. > > It also still seems to me that Makefile.local will still work - > after all, it's above WRKDIR - however, it then takes on the flavor > of global, or site-wide, options settings on a port-by-port basis, > rather than the host-by-host that the name implies it was originally > intended to provide.