Ken Williams wrote:
Hi,
This summary, like any summary, is most appreciated. It helps me to
clarify where I see things differently, though I agree with some of
what's being said here.
On 2/16/06, Tels <[EMAIL PROTECTED]> wrote:
For any module, especially the ones for installing other modules (e.g.
M::B, EUMM, M::I and CPAN) there are three (not nec. distinctive)
crowds:
* A - the original source code author and maintainer.[0]
* D - developers, e.g. other people who want (or must, via
dependencies)
use the module in their code. Often includes A, too.
* U - mere users, who just want (or must, see above) to _use_ the
module's functionality. Can also include A and D.
Fact of the Day:
Any module which wants to replace the current build system (EUMM) must
please[8] all three crowds or it will fail.[1]
M::B is of course trying to please all three of A, D, and U. I had
hoped that would be obvious, but in case it's not, I'm re-stating it.
Pleasing U does, among other things, require to solve the chicken-egg
problem.
Well, M::B is a chicken which knows how to lay itself as an egg. And
CPAN and CPANPLUS or whatever tool know how to install M::B because it
ships with both a Build.PL and a Makefile.PL and has since nearly day
one. So at the top of the dependency tree there's a terminus.
The issue is thus reduced to making sure other distributions can declare
their dependency on M::B in a way that the tools will recognize.
M::B::Compat is our current solution for this. It generates three
different kinds of Makefile.PLs for authors to include with their
distributions. We've put a lot of work into them, which should be
Exhibit A for showing that we care about such users. I'm sure we can
improve our tools, but I do want to make it clear that they exist and
have since April of 2002.
What Module::Build claims is that it pleases A and D. From that is
infered
that U will also be automatically pleased.
I have never ever made such an assertion. I do understand that there
are issues U considers critical that A and D don't really care much
about (unless they're wearing their U hats).
Also, we do indeed try to please U in M::B. Witness for example the
'diff' action, and the fact that a huge motivator for the entire project
for me is to be able to generate *good* rpms/debs/ppms/etc for any
M::B-using CPAN module. There's an immense infrastructure necessary to
do that well, and probably A and D will never care about it at all.
Who is making such an inference, anyway?
So, we have critism from U about not being pleased (Adam writes about
this, for instance). To this there are responses along the lines:
* U might be displeased or not, but D is very pleased[4]:
http://tinyurl.com/du7yc
Bzzzt. Wrong answer.
It's here that you lose me. I don't know if "Bzzzt. Wrong answer" and
the advocacy in the rest of the message is really "summary" fodder.
Anyway, we've identified some things about the Makefile.PLs that can be
improved. We'll do so.
Specific issues we can fix, or at least identify, are great. But I
resent some of the implications going around that our whole philosophy
of the project is wrong, or that somehow we're evil for wanting to
create and release a better build system. These things are complicated,
and if some area is substandard that's because it needs tuits, not
because we don't care about our users.
Ken, I appreciate everything you are doing, and I've always found you
very reasonable.
The comments I'm seeing from end-users (who sometimes wouldn't even know
a MB mailing list exists let alone would join it and have the social
risk of saying something) don't take the reasons for why it's
substandard into account. They only care that "it doesnt' work".
So my suspicion is that the problem is not that Module::Build is
necesarily bad, but perhaps that it is being heavily promoted (to the
point where 10% of CPAN has moved over) before it has been tested (as
Andreas puts it) under Battle Conditions.
And that perhaps we should be advising people to be a bit more cautious
about moving over the Module::Build unless they have a good reason to do
so. (given it's incomplete nature).
And I note I'm now doing the same thing for Module::Install, I don't
recommend people use it unless they need to do something they can't do
with plain MakeMaker. Because MI isn't at 1.00 yet either.
Adam K
