Subject: Re: packages with different LOCALBASE ?
To: Daniel Hagerty <>
From: Alistair Crooks <>
List: tech-pkg
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
>  pkgsrc.

Well, I'd be happy to help (and, to that end, have a look at the EVAL_PREFIX
stuff in, 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.

Interesting idea.


Alistair Crooks (

Tired of slow Internet? Get @Home Broadband Internet