On Fri, 2006-01-27 at 09:25 -0800, Brian Harring wrote:
> On Thu, Jan 26, 2006 at 06:10:08PM +0100, Michael Haubenwallner wrote:
> > Hi,
> >
> > when talking to a colleague of mine (he's using Gentoo-Linux, and wants
> > to use prefixed portage), an idea for the prefix-api came up:
> >
> > Currently, there's the PREFIX variable (among others) for the ebuilds.
> >
> > The idea is to substitute this with a bash-function, echoing a prefix.
> >
> > This function could be defined to get one argument, which is much like
> > the same syntax as the *DEPEND settings, but only for a single package.
> > If no argument, the current package is used.
> >
> > Yes, the current implementation would be simple:
> > prefix() {
> > echo $PREFIX
> > }
> >
> > But the idea behind that is:
> >
> > Once portage could handle interdomain dependencies, the prefix-api need
> > not to be changed to let ebuilds find the prefix of their dependencies.
> >
> > A sample ebuild-snippet:
> >
> > DEPEND="<my-dependency-2"
> >
> > econf-or-src_build() {
> > .../configure \
> > --prefix=$(prefix) \
> > --with-my-dependency=$(prefix "<my-dependency-2")
> > }
>
> Dunno about that construct; aside from violating metadata constant
> rules (realize it's just an example), the prefix optional arg syntax
> seems like an easy way to get bit in the ass if a variable you thought
> was set/had a value, turned out to be [ -z ]
>
> Imo, PREFIX should be "this is where this ebuild is installing",
> grabbing prefix/root location for deps should be a seperate function;
> avoids the issue of different behaviour if an optional arg is
> available (and the potential for people to screw it up).
>
Accepted:
Then keep ${PREFIX} what it is, and have some kind of a
$(prefixof "<my-dependency-2") function ?
prefixof() {
[ $# -eq 1 ] || die "prefixof requires exactly one argument."
echo "${PREFIX}"
}
econf-or-src_build() {
.../configure \
--prefix=${PREFIX} \
--with-my-dependency=$(prefixof "<my-dependency-2")
}
> > Another possible feature in the future (not finished thinking about yet)
> > could be to have portage install each (non-system-)package into a
> > separate prefix within its domain, without need to change prefix-api.
> > This could help ebuild-devs to detect unknown dependencies, which are
> > not found implicitly if not specified at configure-line.
> > Well - only for a testing system, and to be enabled explicitly
> > by setting FEATURES.
> >
> > What do you think about this ?
>
> Gnu stow attempted this- would probably be worthwhile poking them for
> info on prefix issues.
>
> Granted, they're doing symlinks to maintain the appearance of a normal
> install, but still, probably could raid a few tricks from them
> depending on if they ever managed to build up an actual repository of
> packages.
Having those symlinks, for portage there's no more need to have distinct
prefixes for packages, as their executables/libs/headers end up in the
common prefix, and configure continues to find them even if not
specified by the ebuild...
But sure, stow-users should already have found some pitfalls.
>
> ~brian
--
[email protected] mailing list
