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

[Brian Harring]

On Sat, May 07, 2005 at 02:39:20AM +0100, Ciaran McCreesh wrote:
> '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

Surprisingly, not quite true (was fun stating it I'm sure though).


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

Dodging the valid sed criticism, no, a secondary sed would be 
something of a hack.  Substitue the prefix var instead.

Re: changes, yes, things will need changes, and again, as stated 
thrice, those who want the changes are the ones who are stuck doing 
said changes.  In other words, the actual work required to 
cleanse/correct the tree isn't getting dumped on ebuild devs as a whole.  

The change in conventions for writing ebuilds _is_ falling on 
ebuild dev's heads.  

Remember that in the grand scheme of things, the required changes to how 
ebuilds are written is a helluva lot more important then basically 
retrofitting existing ebuilds.

In other words, you would be wise to snipe the suggested changes to 
writing an ebuild, rather then dragging out example after example of 
possible required changes to the tree.  The examples you're dragging 
out basically come down to making sure the ebuild is 'correct' for the 
package.  I can just as quickly drag out example after example of 
potential mistakes ebuild devs can make _now_.

Basically, if the only thing you can point out as a con against this 
glep is changes -the interested parties would have to make to the 
existing tree-, please summarize rather then dragging this out over a 
week.  If you're after arguing that the potential complexity involved 
in mapping an ebuild into a nonstandard prefix is too large, summarize 
and state that, etc.

Getting a bit tired of repeatedly stating (whether irc or ml) "yes, 
the existing tree would require modification, and yes, you don't have 
to do the heavy lifting, those interested do".

If this portion of the discussion is to continue, please split 
it off into a seperate thread, thus far it's hijacked the discussion 
and is more centered on crappy ebuilds/packages, rather then potential 
changes.  Not saying it's not a valid point, just saying "yeah, you 
got your point across, now can we move on to the other portions that 
need discussion?".  Remember that gleps go through several rounds of 
discussion, I'd like to see this round keep moving rather then get 
stuck in the mud.


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

Could you break it down to "if I'm going into home, I need xyz at the 
home level rather then global/usr" ?
as in something along the lines of 
if dep_installation_target some-vim-dep home; then
	# do the home equiv
else
	# do the global equiv
fi;

?
~brian
-- 
gentoo-dev@g.o mailing list