| 1 |
On Thu, Oct 06, 2005 at 02:23:47AM +0100, Ciaran McCreesh wrote: |
| 2 |
> On Wed, 5 Oct 2005 20:17:40 -0500 Brian Harring <ferringb@g.o> |
| 3 |
> wrote: |
| 4 |
> | > The issue is that you need to fix autoconf before you can claim that |
| 5 |
> | > any non-trivial test case works correctly. |
| 6 |
> | |
| 7 |
> | And how are you going to verify autoconf works perfectly without |
| 8 |
> | testing it? |
| 9 |
> |
| 10 |
> Can't. Dead easy to verify that it will break without testing it, |
| 11 |
> though. Just look at the source. |
| 12 |
Break is a bit heavy, considering autoconf's usage of /bin/sh is |
| 13 |
pretty limited in terms of syntax. Looking at the source, it'll |
| 14 |
revert to / for certain bins. |
| 15 |
|
| 16 |
A forced autoreconf with a patched autoconf/autotools |
| 17 |
is required, but again, doesn't do jack with out testing. |
| 18 |
|
| 19 |
> | The point I'm making is that the only thing required of *portage*, is |
| 20 |
> | the prefix var being used internally, and handed down to the ebuilds. |
| 21 |
> | |
| 22 |
> | Ironing out the ebuild cruft is left to those who want it. Again, |
| 23 |
> | where is the hold up for *portage*? |
| 24 |
> |
| 25 |
> That's rather short-sighted... Portage is irrelevant without the |
| 26 |
> ebuilds. |
| 27 |
|
| 28 |
And ebuilds are irrelevant without portage. Point? |
| 29 |
My point experimentation can start for addressing the issues you keep |
| 30 |
pointing at still stands. |
| 31 |
|
| 32 |
> |
| 33 |
> | What's the problem? Why the 101 holes before they even can attempt |
| 34 |
> | it? If you're after shooting the idea down (as I suspect), state so |
| 35 |
> | rather then death by a thousand cuts. Saves us time, really. |
| 36 |
> | |
| 37 |
> | Hell, haubi's patch already lays the ground work for testing it. I'm |
| 38 |
> | not seeing why you're being negative about people even working on it. |
| 39 |
> |
| 40 |
> Because a botched solution is worse than no solution at all. You've |
| 41 |
> seen the mess we end up with when people start working with a |
| 42 |
> half-arsed initial setup. |
| 43 |
|
| 44 |
Well plan the sucker out then, as you advocated, or sit back and let |
| 45 |
them jump in and start working it out. |
| 46 |
|
| 47 |
Perhaps they'll decide it's completely unworkable (I doubt it, |
| 48 |
considering the fact fink's crappy handling of building has made it |
| 49 |
this far), or perhaps they'll get it working and you won't have as |
| 50 |
many holes to point at. |
| 51 |
|
| 52 |
Regardless, it's their time to spend working on it. Either chip in, |
| 53 |
or offer _constructive_ advice, or plain step back and let them try to |
| 54 |
get it working. |
| 55 |
|
| 56 |
Note the constructive. Stating it won't work and pulling a new reason |
| 57 |
why isn't constructive, pointing out each issue as you see it so they |
| 58 |
can address it (if it's an issue) is a bit more constructive. |
| 59 |
~harring |
Archives