Mailing List Archive: prefix ebuild's api suggestion

prefix ebuild's api suggestion

Jan 26, 2006, 10:10 AM

Post #1 of 15 (5905 views)

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")
}

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 ?

-haubi

--
gentoo-osx@gentoo.org mailing list

Re: prefix ebuild's api suggestion [ In reply to ]

grobian at gentoo

Jan 26, 2006, 10:22 AM

Post #2 of 15 (5805 views)

Permalink

On 26-01-2006 18:10:08 +0100, Michael Haubenwallner wrote:
> 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.

This is really a great dream. This would allow one to use the stuff
provided by the system as long as sufficient, and also would allow the
Gentoo distribution to support user installs of packages in a way I
think.

> What do you think about this ?

I absolutely like the modular and generic approach of the idea. I guess
it's up to the portage guys to see how far this can be implemented and
activated. It makes no use to have the function if it will never do
anything else but echoing the ${PREFIX} var.

--
Fabian Groffen
Gentoo for Mac OS X Project
--
gentoo-osx@gentoo.org mailing list

Re: prefix ebuild's api suggestion [ In reply to ]

ndimiduk at gentoo

Jan 26, 2006, 10:23 AM

Post #3 of 15 (5812 views)

Permalink

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:

<snip> (no room to comment at this time)

> 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.

This sounds a bit like the intentions of DragonflyBSD. Am I
miss-understanding you?

--
Nick Dimiduk
Gentoo Developer
ndimiduk (at) gentoo (dot) org
--
gentoo-osx@gentoo.org mailing list

Re: prefix ebuild's api suggestion [ In reply to ]

kito at gentoo

Jan 26, 2006, 8:27 PM

Post #4 of 15 (5811 views)

Permalink

On Jan 26, 2006, at 11:10 AM, Michael Haubenwallner wrote:

> 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.

So really, portage needs to imitate pkgconfig on some level, probably
just start by looking in the vdb, shouldn't be too hard in a single
domain/vdb situation. The interdomain bit is going to depend on many
factors unknown to me, and not something we should pursue in the
current 2.x codebase, but I assume saviour has at least the entry
points to make this possible.

>
> 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.

This probably isn't as crazy as you might think. With ROOT, and a
little more work on PREFIX, it should just be a matter of setting
these appropriately on a per package basis. The other possible use
for this would be creating package bundles with complete dep trees
suitable for distribution.

>
> What do you think about this ?
>

=)

--Kito

--
gentoo-osx@gentoo.org mailing list

Re: Re: prefix ebuild's api suggestion [ In reply to ]

sebastien at atlantic-creations

Jan 27, 2006, 1:28 AM

Post #5 of 15 (5808 views)

Permalink

I will be out of the office until Monday, January 30, 2006.

For emergencies please call 334.728.1868

Thanks,

SÃ©bastien Arnaud
@tlantic web creations, llc
sebastien@atlantic-creations.com
334.239.4481

--
gentoo-osx@gentoo.org mailing list

Re: prefix ebuild's api suggestion [ In reply to ]

michael.haubenwallner at salomon

Jan 27, 2006, 2:07 AM

Post #6 of 15 (5808 views)

Permalink

On Thu, 2006-01-26 at 12:23 -0500, Nick Dimiduk wrote:
> 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:
>
> <snip> (no room to comment at this time)
>
> > 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.
>
> This sounds a bit like the intentions of DragonflyBSD. Am I
> miss-understanding you?

Huh - what is DragonflyBSD, never heard before.

Found dragonflybsd.org...

Well - have read the Goals->packages there, seems that they are after
some similar goals/address similar problems. Do you mean that ?

-haubi

--
gentoo-osx@gentoo.org mailing list

Re: prefix ebuild's api suggestion [ In reply to ]

michael.haubenwallner at salomon

Jan 27, 2006, 2:09 AM

Post #7 of 15 (5804 views)

Permalink

On Thu, 2006-01-26 at 21:27 -0600, Kito wrote:
> On Jan 26, 2006, at 11:10 AM, Michael Haubenwallner wrote:
>
> > 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.
>
> So really, portage needs to imitate pkgconfig on some level, probably
> just start by looking in the vdb, shouldn't be too hard in a single
> domain/vdb situation. The interdomain bit is going to depend on many
> factors unknown to me, and not something we should pursue in the
> current 2.x codebase, but I assume saviour has at least the entry
> points to make this possible.

Sure, not in 2.x, just to be prepared.

>
> >
> > 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.
>
> This probably isn't as crazy as you might think. With ROOT, and a
> little more work on PREFIX, it should just be a matter of setting
> these appropriately on a per package basis. The other possible use
> for this would be creating package bundles with complete dep trees
> suitable for distribution.

Wow, ideas over ideas, and they all are conceivable!

-haubi
--
gentoo-osx@gentoo.org mailing list

Re: prefix ebuild's api suggestion [ In reply to ]

ferringb at gentoo

Jan 27, 2006, 10:25 AM

Post #8 of 15 (5812 views)

Permalink

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

Re: prefix ebuild's api suggestion [ In reply to ]

dirk.schoenberger at sz-online

Jan 27, 2006, 12:10 PM

Post #9 of 15 (5810 views)

Permalink

> > > 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.
> >
> > This probably isn't as crazy as you might think. With ROOT, and a
> > little more work on PREFIX, it should just be a matter of setting
> > these appropriately on a per package basis. The other possible use
> > for this would be creating package bundles with complete dep trees
> > suitable for distribution.

> Wow, ideas over ideas, and they all are conceivable!

Because we are at strange ideas, would it be possible to introduce
something like
$PREFIXES, where this is a list of directories, say

$PREFIXES=/:/gentoo

If I want to emerge a package, the package should be installed into the
first matching
PREFIX
If problems occur, say because there exist a un-manged version of some
package, the prefix is black-listed for this packaage, and the next
directory is choosen.

This black-listing can also be done by a user.

So I could emerge (and use), say app-text/editors into PREFIX=/, while,
say dev-lan/python is emerged into /gentoo

This would leave a problem how the correct executable and / or their
corresponding resources are found.
Say, imagemagic wants to call /usr/bin/gs, but ghostscript is really
installed into /gentoo/usr/bin/gs

Regards
Dirk

--
gentoo-osx@gentoo.org mailing list

Re: prefix ebuild's api suggestion [ In reply to ]

ferringb at gentoo

Jan 27, 2006, 12:29 PM

Post #10 of 15 (5812 views)

Permalink

On Fri, Jan 27, 2006 at 08:10:41PM +0100, Dirk Sch??nberger wrote:
> > > > 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.
> > >
> > > This probably isn't as crazy as you might think. With ROOT, and a
> > > little more work on PREFIX, it should just be a matter of setting
> > > these appropriately on a per package basis. The other possible use
> > > for this would be creating package bundles with complete dep trees
> > > suitable for distribution.
>
> > Wow, ideas over ideas, and they all are conceivable!
>
> Because we are at strange ideas, would it be possible to introduce
> something like
> $PREFIXES, where this is a list of directories, say
>
> $PREFIXES=/:/gentoo
>
> If I want to emerge a package, the package should be installed into the
> first matching
> PREFIX
> If problems occur, say because there exist a un-manged version of some
> package, the prefix is black-listed for this packaage, and the next
> directory is choosen.

Portage currently doeesn't really track prefix in the prefix branch;
it's a compile time directive that just makes portage build stuff with an
offset. Getting into what you're requesting, means portage will have
to be aware of the prefix (and capable of swiveling it), which is
getting into the domain side of things.

That's getting into interdomain crap; current intentions (and they're
just intentions since I haven't yet written any interdomain code) is
that you define the domain you wish to manage; this includes a PREFIX
definition. During resolution, that domain reaches up to the parent
domain (PREFIX=/), and queries it for what's available and where;
that's how it would handle satisfying a python dep when you're
targetted prefix is home (fex). What you seem to be asking is the
ability to state "I want this merged, globally if possible, else in a
prefix", which is a resolver decision, and reliant on the domain
concept.

> This black-listing can also be done by a user.
Currently,
EAPI="prefix"
means that the ebuild can be installed to *any* prefix (implicitly /);
the change you're requesting (imo) is beyond the focus of the prefix
branch. Prefix branch is strictly having ebuilds merged to an alt
prefix- selection of which domain/prefix to merge to is a bit higher
up in the design of things.

~harring

Re: prefix ebuild's api suggestion [ In reply to ]

ndimiduk at gentoo

Jan 27, 2006, 1:39 PM

Post #11 of 15 (5815 views)

Permalink

Michael Haubenwallner wrote:
>> This sounds a bit like the intentions of DragonflyBSD. Am I
>> miss-understanding you?
>
> Huh - what is DragonflyBSD, never heard before.
>
> Found dragonflybsd.org...

Yes, I'm specifically talking about
http://www.dragonflybsd.org/goals/packages.cgi
--
gentoo-osx@gentoo.org mailing list

Re: prefix ebuild's api suggestion [ In reply to ]

dirk.schoenberger at sz-online

Jan 28, 2006, 2:35 AM

Post #12 of 15 (5813 views)

Permalink

> That's getting into interdomain crap; current intentions (and they're
> just intentions since I haven't yet written any interdomain code) is
> that you define the domain you wish to manage; this includes a PREFIX
> definition.

So if I understand you correctly, the plan is to make "prefix" work first
and add "domain" / "resolver" later?
The problem is that I see that adding a "resolver" layer (which would need
to work at runtime, on a local system)
would not only break portage, but instead any emerged package.

> During resolution, that domain reaches up to the parent
> domain (PREFIX=/), and queries it for what's available and where;
> that's how it would handle satisfying a python dep when you're
> targetted prefix is home (fex).

Is this parent-child relationship really needed? Would it be possible /
feasible to
do a pure parallel relationship. I.e. You have PREFIXES=/gentoo1:/gentoo2
Or a reverse parent-child relationship, i.e PREFIXES=/gentoo:/

Regards
Dirk

--
gentoo-osx@gentoo.org mailing list

Re: Re: prefix ebuild's api suggestion [ In reply to ]

sebastien at atlantic-creations

Jan 28, 2006, 2:51 AM

Post #13 of 15 (5809 views)

Permalink

Re: prefix ebuild's api suggestion [ In reply to ]

michael.haubenwallner at salomon

Jan 30, 2006, 7:09 AM

Post #14 of 15 (5815 views)

Permalink

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
--
gentoo-osx@gentoo.org mailing list

Re: prefix ebuild's api suggestion [ In reply to ]

dirk.schoenberger at sz-online

Jan 30, 2006, 8:56 AM

Post #15 of 15 (5814 views)

Permalink

> 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.
>

Agreed.
And for the Gentoo-MacOSX case in a pure root PREFIX="/" the symlink would
(attempt to) overwrite the actual executable.

Regards
Dirk

--
gentoo-osx@gentoo.org mailing list