On Thu, Oct 06, 2005 at 02:23:47AM +0100, Ciaran McCreesh wrote: > On Wed, 5 Oct 2005 20:17:40 -0500 Brian Harring <[EMAIL PROTECTED]> > 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
pgpLpvBGoQzGq.pgp
Description: PGP signature
