Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[Brian Harring]

On Thu, Oct 06, 2005 at 03:01:12AM +0100, Ciaran McCreesh wrote:
> On Wed, 5 Oct 2005 20:48:26 -0500 Brian Harring <ferringb@g.o>
> wrote:
> | > The sensible place to start experimenting is by adapting existing
> | > ebuilds and tinkering with ebuild.sh, not by adding something which
> | > may or may not end up being relevant to portage proper.
> |
> | Bluntly, what the hell do you think we're talking about here?  In
> | case you haven't caught on, there *are* portage modifications that
> | have to go with it, meaning more then ebuild.sh.
>
<snip lots of "you're doing something I think is dumb/I don't 
agree/slams at pvdabeel/lv/others who have attempted things in the tree">

Clarification of two things.

First- this is external, including the patch.  So comparing it to 
attempts that were done in a live tree is a bit of 
intentional bullshit/rhetoric.  

The entire intention of this is to work it out, *outside* of the tree, 
something those involved know.  You seem to be out of the loop, not 
surprising considering your attitude towards this whole attempt.

Second- Not having a clue about what the full set of modifications are 
going to be until you solve the ebuild side of it is *exactly* why 
people have to jump in and actually test the damn thing.  You can solve 
as much of it up front as you know will be an issue, testing will reveal the 
additional issues.  Under your suggested route, nothing is 
accomplished (potentially the reason you're suggesting all issues up 
front be addressed regardless of whether or not if they'll actually 
_be_ issues).

What you're offering as a proposed/sane route is a route that produces 
nothing due to the fact you think everything must be solved up front, 
regardless if it turns out to be an issue or not (let alone 
identifying everything that may or may not be an issue) .  Get the 
basic portage support up, they iron out the base mods initially needed, 
and jump in and identify the bugs that crop up further.

Essentially, lets see how well this actually works out, rather then 
listening to you run your mouth about how it's a bad idea whenever it 
comes up, and all of these things will be issues (/bin/sh usage isn't 
an issue for the initial test target of osx).

Either way, they're doing the work, you aren't, and you really don't 
have *any* say over their efforts until they finalize a solution 
and bring it to *devs* (not just you) for merging into mainline.

So bluntly, shut up and let those who you think are being retarded, 
be retarded.  Discussions on this list regarding those attempts 
shouldn't be heckled unless you're contributing to those efforts (and 
I truly mean *contributing*, not trying to punch holes in embryonic 
efforts that are trying to get off the ground addressing the major 
issues up front).

Regardless, your points (repeatedly restated in the varying forms) 
have been noted, and those who are interested have no reason to not 
move forward with ironing out an implementation, and testing it.

I suggest you sit quietly and let them do their work, rather then 
riding their asses.

You might be surprised at what they come up with. 

If/When they push for inclusion, the merits of their efforts their 
solution (and outstanding issues) will be evaluated then.  Back 
off and let them do their work, it's not affecting you in anyway, so 
again, you really don't have any say in it till they push for 
mainline.

So... yeah.  I'll post the prefix support backport patch once it's 
done, few days I'd expect since there is a fair amount of autotooling 
to deal with also.

Those interested, I suggest you chip in, whether to spite ciaran 
(good or bad reasons, doesn't matter, result does >:), or to get this 
feature you want realized.
~harring