Subject: Re: packages with different LOCALBASE ?
To: Daniel Hagerty <firstname.lastname@example.org>
From: Alistair Crooks <AlistairCrooks@excite.com>
Date: 11/13/2000 09:43:09
On Sun, 12 Nov 2000 19:18:58 -0500, Daniel Hagerty wrote:
> [ No holy wars, please. Just because you believe the current thing to
> be the one true way doesn't make you right or wrong. ]
Even if you're the one who looks after pkgsrc, sends out monthly summaries,
and tags it for the releases? :-)
> I started rebuilding my universe lately, and wanted to use pkgsrc
> to save me some grunt work. Ran into some issues with my world view
> vs pkgsrc's world view.
> Right now, a lot of packages assume that LOCALBASE is a constant
> across all builds. This is reasonable enough, but prevents
> configurations that I've been doing for a long time.
> I like to seperate GNU packages into a seperate directory
> heirarchy from everything else. This is my preferred method of
> dealing with GNU packages that often overlap system binaries (like
> fileutils), instead-of/in-parallel-to the g- prefix that netbsd's
> packages use. Users can readily choose which set of utils they'd like
> with a simple twiddling of path ordering, rather than having a large
> collection of aliases, or retraining their fingers.
Ah - that's the first time I've come across that sort of a distinction.
> Not knowing pkgsrc very well, I can't think of a general solution
> for the LOCALBASE variability problem. Removing the assumption is
> probably doable, but would take work.
> For this specific case, I could imagine a GNUBASE variable, but
> the "what is/isn't GNU" question gets kind of hairy & arbitrary.
> Anyway, I was curious what thoughts on this would be. I'd be
> willing to do work and patches to make my way of thinking work with
Well, I'd be happy to help (and, to that end, have a look at the EVAL_PREFIX
stuff in bsd.pkg.mk, which works out where a pre-requisite package was
installed, rather than using a hard-coded LOCALBASE or X11BASE definition,
primarily meant for the xpkgwedge package), but don't count on our being
able to roll your changes back into pkgsrc - it depends what others think,
and how pervasive the changes are. You could, of course, keep them in a
private change so that cvs can manage it in your own pkgsrc tree.
Alistair Crooks (email@example.com)
Tired of slow Internet? Get @Home Broadband Internet