Re: [gentoo-dev] new glep draft: Portage as a secondary package manager

[Ciaran McCreesh]

On Fri, 6 May 2005 20:05:18 -0500 Brian Harring <ferringb@g.o>
wrote:
| On Fri, May 06, 2005 at 02:28:49PM +0100, Ciaran McCreesh wrote:
| > The problem isn't the packages. The problem is the ebuilds.
| Agreed, although seemed to take a bit of dancing to get done to the 
| fact that yes, changing the prefix has a good chance of working.
| 
| From there, we're back to the old two step econf/eclasses _do_ address
| a sizable portion of ebuilds in the tree ;)

More to the point, they *don't* address a sizable portion of the ebuilds
in the tree.

| Not much for a keyword route personally, since (imo) it's a slight 
| perversion of the focus of keywords.  If the keywording route was 
| taken, would need to either duplicate existing keywords (have 
| x86/~x86, and x86-weirdo-prefix ~x86-weirdo-prefix), or require two 
| specific keywords being set (x86 and weirdo-prefix from the example 
| above).  
| 
| I'd suspect your metadata addition (which needs a better name then 
| ICANINSTALLTO) is the best route.

That was what I was proposing. Not KEYWORDS, a new variable. Which needs
a better name than ICANINSTALLTO.

| > | So, fink demonstration of --prefix hackery?
| > 
| > If you want a better example, try either SGI or Sun's GNU tools
| > ports. But they don't use ebuilds either.
| Well, main point was that the underlying packages _can_ swing this 
| type of hackery for the most part, what is needed is a tweak to our 
| ebuild conventions to allow for it.

'tweak' is too mild a term... As far as I can tell I'm the only person
who's bothered to actually even try to look at this from an ebuild
perspective -- not pretty... For every package in the tree that has a
sed -e 's,/usr/local,/usr,g' there's another that would need a sed
turning /usr into whatever prefix ends up as, and it's not at all
obvious what they are. It gets even worse when you consider all the
stuff with #!/usr/bin/blah hardcoded that will need changed to use our
interpreter prefix -- these are very tricky to spot if you have a
braindead vendor-supplied interpreter in /usr/bin too.

Sure, it can be done, but not all at once, hence me screaming whitelist.

| Meanwhile, iirc from the last irc conversation on this, either you or 
| dsd brought up the point of needing to be able to query if (using vim 
| as an example) vim-core was $home, rather then usr|$PREFIX.  Care to 
| elaborate a bit?  Mainly wondering if to encompass your requests, it 
| might require extra metadata from the depend standpoint.

Ok, say we use ICANINSTALLTO (name!). Then if we have "prefix" as the
destination, there's no problem, because we know that all our deps are
installed in ${PREFIX} as well. However, if we're installing to "home",
we need to know where our deps are -- for "home" installs I'm presuming
we don't force a full dep tree in "home" (unlike for "prefix"). This
*could* still be done with ${PREFIX} I guess? Or to avoid confusing
things, ${DEPS_PREFIX}? Not really sure...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm