From owner-freebsd-ports@FreeBSD.ORG Thu Sep 2 18:17:03 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 F363116A4CE for ; Thu, 2 Sep 2004 18:17:02 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id C19AD43D45 for ; Thu, 2 Sep 2004 18:17:02 +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 i82IHUMs029432; Thu, 2 Sep 2004 11:17:30 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i82IHUIh029431; Thu, 2 Sep 2004 11:17:30 -0700 Date: Thu, 2 Sep 2004 11:17:30 -0700 From: Brooks Davis To: Mike Message-ID: <20040902181730.GC3801@odin.ac.hmc.edu> References: <19DD9455-FCF9-11D8-B720-00039312D914@fillmore-labs.com> <1094148684.78074.18.camel@torres> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V88s5gaDVPzZ0KCq" Content-Disposition: inline In-Reply-To: <1094148684.78074.18.camel@torres> 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-ports@freebsd.org cc: Oliver Eikemeier Subject: Re: PREFIX "cleverness" 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, 02 Sep 2004 18:17:03 -0000 --V88s5gaDVPzZ0KCq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 02, 2004 at 02:11:24PM -0400, Mike wrote: > On Thu, 2004-09-02 at 11:59, Oliver Eikemeier wrote: >=20 > > make PREFIX=3D'/usr/local/${PORTNAME}' install >=20 > I'd thought of that, but I wasn't certain if there was an automated way > to do this (via make.conf). >=20 > > You need to build a link farm from LOCALBASE to the files installed by= =20 > > your port, since other ports expect them to be there. Another=20 > > consequence is that new CONFLICTS checking routines are required. > [..] > > Your degree of insanity depends on just what you are trying to=20 > > accomplish. If you want to do this `just because it can be done' - yes= .=20 > > If you believe it will better separate the packing lists of ports -=20 > > maybe. If you attempt to pkgsrcify the FreeBSD ports collection - who= =20 > > knows. >=20 > To better explain, at my place of work (and I should have posted with my > work address, since that's also my subscribed address) we use a locally > built system called xhier for shipping packages and binaries and config > files and such around.=20 > http://www.math.uwaterloo.ca/mfcf/documentation/xhier/ has papers from a > presentation made at LISA '91 for the morbidly curious. It's an old > paper, but it's an old system. Basically the intention was (and is) to > provide some level of homogenity across multiple platforms. I could go > on, but I won't since it'd start to get off-topic. >=20 > One of the conventions used is packages are installed under > /software/packagename (where packagename may - and ought to - include a > version number). Programs can be configured to appear in default paths > or not. Links are made as required into system locations. There's a > utility called showpath that can be used to set paths programatically.=20 > Packages are built on a single machine (architecture master or > archmaster) and then distributed out to clients. >=20 > Practically, this can eliminate the idea of package conflicts altogether > (so I'm not so concerned about that) because it just doesn't put the > conflicting packages into the default path - only one package can be the > default version of a given application at any time. (So gcc-3 can point > to gcc-3.3, but gcc 3.2 and 3.4 can be installed as well. You just need > to tell your Makefiles where to look instead.) >=20 > Currently there's some interest in using FreeBSD machines in our > department, but one of the sticking points is (as it is with any new OS > or architecture) "can xhier work on it". I've set up several projects > that have long been sorely needed on a FreeBSD machine on the "it's > easier to beg forgiveness than to ask permission" premise, but those > projects have now attracted attention so I'd like to head off complaints > about FreeBSD lacking xhier before they even come up. >=20 > Conventionally packages are built on the archmasters by hand: > "./configure --prefix=3D/software/packagename" usually does the trick.=20 > However, I'd like to take advantage of the ports system if I can. The > systems for configuring and patching and such are already there, after > all; it will save some steps, and plus I'd be able to push it even > more: "Look, I xhiered this package in 10 minutes on FreeBSD, it took > you a full day for Solaris." >=20 > What I'd envisioned was building the ports on the archmaster and then > using xhier to ship them to client machines, same way we do with other > arches (but maybe even better if I could do "make package" and ship the > package tarball across to be installed with pkgadd). >=20 > Or maybe I'm making too much work for myself, I don't know. But I was > curious as to how workable such a scheme would be. From yours and > Sergey's responses, I'm still unsure so I guess I'll have to try :-) - > but if you have any more comments based on what I've said I'd be glad to > hear them. Due to the hardcoding of LOCALBASE in dependencies, I think you will have a hard time getting this sort of thing to work with ports unless you also create a symlink farm and point LOCALBASE to it. You might actually consider using NetBSD's pkgsrc. It has a lot less packages, but is supports installations of many current packages in a more xhier compatable fasion using the pkgviews concept. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --V88s5gaDVPzZ0KCq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBN2O5XY6L6fI4GtQRAqd2AKDgqkTeUce8xoxZ16ITtrrskvbaYgCgki1t 00ufQacXBKxDpdWzLatWAss= =u5Hz -----END PGP SIGNATURE----- --V88s5gaDVPzZ0KCq--