Re: [Module::Build] Asking the unaskable

[David G. <da...@hy...>]

Johan Vromans wrote:
>> I'm unfortunately not very well-versed in Module::Install, so I
>> probably can't comment too much about it.
> 
> As for many modules, there's very little (mostly: nothing) that needs
> to be built. It's just a matter of dropping the modules in the right
> place. For purposes like this, a simple installer (as opposed to a
> builder) would suffice. AFAIK, M::I tries to be just that: an
> installer. And, as already noticed, it includes its code in the kit so
> it doesn't need any modules pre-installed.

Here's an example of the problems with Module::Install in its current 
state:  I recently tried manually upgrading HTTP::Server::Simple to 0.18 
after upgrading to Win32 ActiveState 5.8.8 (which supposedly supports 
cpan out of the box).  However, H::S::S has M::I version 0.52, which 
uses an @INC hack which is incompatible with the way Config.pm is 
modified by AS5.8.8.  The latest M::I is version 0.61, which fixes that bug.

My interim fix, based on advice from Jesse, was to install M::I 0.61, 
delete the inc/ directory, and then run Makefile.PL, which recreates inc 
using 0.61 and then installs fine.

The "proper" fix is to wait until Jesse releases H::S::S 0.19, which 
bundles M::I 0.61 (or better).

So, at least in its current alpha/beta state, using M::I means that 
you've hooked yourself on to that dependency chain.  I currently 
maintain about 17 CPAN distributions.  If I used M::I for all of them, 
then whenever a bug is found in M::I, or whenever something else changes 
that breaks something in M::I, I would need to bump versions, repackage 
and re-release all 17 distributions to ensure that everyone will be 
successful installing my module.

Yes, that can be automated, but it's still a big philosophy difference. 
  And I cringe thinking about the scenario where hundreds of 
distributions all version bump and resubmit to PAUSE every time that 
M::I changes versions to fix a bug for some platform.

Regards,
David