demerphq wrote:
On 4/2/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:
demerphq wrote:
On 4/1/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:
> Similarly
if somebody has an error in their Build.PL or Makefile.PL are you
going to say that the "installer" doesnt work?
Yes, absolutely.
So you would file a bug with ExtUtils::MakeMaker or Module::Build when
the pre-build script that accompanies a script has a syntax error in
it?
No, you'd file it against the distribution that contained the
Makefile.PL or Build.PL.
Ah so, you've changed your position somewhat then eh? I guess you dont
think its a bug in the installer anymore? I mean if its a bug in the
installer why would you report the matter to the distribution author?
Not at all, I'm probably just using a different terminology.
Makefile.PL is the installer.
Build.PL is the installer.
ExtUtils::MakeMaker and Module::Build are modules used to write installers.
If there's a bug in the installer, it's the author who wrote the
installer's fault and you file a bug against the distribution.
If there's a bug in the module used to write the installer, you file it
against the library.
This all makes sense if you ignore internals.
Just because they implement the installer using a particular library,
doesn't mean you blame the library for their mistakes.
You mean just because something fails duing installation doesnt mean
its a problem with the installer?
If something fails during installation, then initial blame lies with the
distribution. If you can determine that the source of the bug is the
library that the installer is using, and the problem applies to ALL
installers using that library, then you pass blame up the line.
If you ignore internals and look at this problem in terms of
responsibility, this all makes perfect sense.
It's the responsibility of a Makefile.PL to install a distribution, or
to explain why the distribution cannot be installed.
In some of these cases, the surrounding CPAN client can resolve these
unmet dependencies and continue with the install.
If a module uses a dependency and the dependency is fatally broken,
responsibility still sits with the module, if not for the bug itself,
then for choosing to use a broken module instead of one that isn't broken.
When you choose your dependencies, you also choose to inherit their baggage.
Where a specific line of code is wrong, or how some internal algorithm
works are implementation issues deriving from how you handle
responsibility and the choices you make.
Adam K
