On Thu, Oct 06, 2005 at 02:23:47AM +0100, Ciaran McCreesh wrote:
> On Wed, 5 Oct 2005 20:17:40 -0500 Brian Harring <ferringb@g.o>
> wrote:
> | > The issue is that you need to fix autoconf before you can claim that
> | > any non-trivial test case works correctly.
> | 
> | And how are you going to verify autoconf works perfectly without 
> | testing it?
> 
> Can't. Dead easy to verify that it will break without testing it,
> though. Just look at the source.
Break is a bit heavy, considering autoconf's usage of /bin/sh is 
pretty limited in terms of syntax.  Looking at the source, it'll 
revert to / for certain bins.  

A forced autoreconf with a patched autoconf/autotools 
is required, but again, doesn't do jack with out testing.

> | The point I'm making is that the only thing required of *portage*, is 
> | the prefix var being used internally, and handed down to the ebuilds.
> | 
> | Ironing out the ebuild cruft is left to those who want it.  Again, 
> | where is the hold up for *portage*?
> 
> That's rather short-sighted... Portage is irrelevant without the
> ebuilds.

And ebuilds are irrelevant without portage.  Point?
My point experimentation can start for addressing the issues you keep 
pointing at still stands.

> 
> | What's the problem?  Why the 101 holes before they even can attempt 
> | it?  If you're after shooting the idea down (as I suspect), state so 
> | rather then death by a thousand cuts.  Saves us time, really.
> | 
> | Hell, haubi's patch already lays the ground work for testing it.  I'm 
> | not seeing why you're being negative about people even working on it.
> 
> Because a botched solution is worse than no solution at all. You've
> seen the mess we end up with when people start working with a
> half-arsed initial setup.

Well plan the sucker out then, as you advocated, or sit back and let 
them jump in and start working it out.

Perhaps they'll decide it's completely unworkable (I doubt it, 
considering the fact fink's crappy handling of building has made it 
this far), or perhaps they'll get it working and you won't have as 
many holes to point at.

Regardless, it's their time to spend working on it.  Either chip in, 
or offer _constructive_ advice, or plain step back and let them try to 
get it working.

Note the constructive.  Stating it won't work and pulling a new reason 
why isn't constructive, pointing out each issue as you see it so they 
can address it (if it's an issue) is a bit more constructive.
~harring