To add to this, sorry for the spam but I think this is relevant/important. A lot of the discussion on this list seems to assume that those involved consider modifying the AxKit code itself to be a reasonable solution ... to me that's just not an option. Sure, I could probably do it (after a week of learning more perl) but I'm not interested and I'd rather spend my time learning XSLT etc. So suggestions of the nature of "it could be hacked to make that work" are somewhat unhelpful.
I won't speak for anyone else here but I do understand your frustration.
Reality is, though, that AxKit is an Open Source project and that implies several things: First, that it is a volunteer effort-- every line code is the result of someone either needing to meet their own specific requirement, or having a good idea and enough free time and chutzpah to implement it.
Second, AxKit being OSS means that, sometimes, more is expected of its users. Granted, patching the AxKit source is not always an option for for everyone (even if they do know Perl) but if a person can't patch, the very least they can do is provide a detailed report that includes a reproducible test case, stripped down to the minimum needed to expose the suspected bug.
We share with the hope that others will share as well, and that the sum of that sharing will make a better AxKit for everyone.
Now, let's talk about the "AxKit bugs" that you've posted here in the last week..
First was the Debian 2.2 iconv problem...
"turns out he's running debian 2.2 which has a known problem detecting iconv. The workaround apparently is either something very complex involving testing versions of libc6 or to hack the makefile to skip the test on iconv (since it just thinks it doesn't work, it actually does work apparently)."
Perhaps you might explain how a known problem on a particular version of a particular Linux distribution is exactly an "AxKit problem"? It looks like none the the AxKit commiters run this particular flavor (I don't), so there's no way for us to to even duplicate the problem, let alone create a work-around for potato's braindeadedness. What do you honestly expect us to do?
I'm sure we all wish that AxKit were always a painless installation on every variant of every platform, but the truth is that AxKit glues together a lot of complex libraries that we don't control and if one of those libraries has problems on a given platform the best we can do is try work around it if we can.
Did you try commenting out the checks for iconv in lib/Apache/AxKit/Makefile.PL as your friend suggested? Seems to me that would work around Debian 2.2's bad behavior nicely. No?
Next we have the "AxKit and xsltproc give different results" post...
Here you provide copious amounts of information, but never once simply state *what* the differences are, nor do you even attempt strip things down to a minimal case that duplicates the problem. Do you honestly expect that we should not only help you solve your problem, but help you define what the problem is in the first place?
I could easily nuke you back to the Stone Age for what I consider to be a selfish and demanding attitude, but I won't. For the most part, I find the ideas that you put forth here to be an interesting part of the chorus and I'd hate to lose them. That said, however, you need to seriously re-examine your expectations about value, collaboration, and whose job it is to solve your problem du jour.
-kip
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
