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
--
[email protected] mailing list
