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). > 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. ~brian
pgpKuBKQTK0Q3.pgp
Description: PGP signature
