Re: [Module-build-general] ANNOUNCE: CPAN-MakeMaker-0.10

[Ken W. <ke...@ma...>]

On Monday, October 28, 2002, at 12:42  AM, Brian Ingerson wrote:
> You have to make sure that an *installed* copy of M::B reloads the local
> copy. The installed version will always be found first. But ultimately,
> it's the local copy you want to execute, because that is the one that
> the module author configured his distribution for. This is *essential*.
> If you do it, you'll never have versioning problems. If you don't you'll
> be plagued by them.

Suppose there's a security bug in M::B, though - if I adopt the above 
policy, a user couldn't just update M::B on their system to fix the 
bug.  They'd also have to make sure all software they installed later 
that uses M::B also had a fixed version.  That

> One problem the current M::B faces is that it not only needs to get a
> copy of M::B on every install (an extremely formidable task in its own
> right)

It's not too hard.  The current pass-through Makefile.PL lists M::B as a 
dependency, so CPAN.pm (and similar) will install it.


> it also needs to have a compatible version of itself everywhere.
> How do you advance?

By having authors list the required version of M::B as a build 
dependency.


> If you do the self install route, you have one other issue to tackle.
> What happens to all the existing M::B installs? They don't know how to
> play the game. They must be removed, or you must change your module
> name. I ran into this problem with Inline::MakeMaker, the precedent to
> C::MM. I was going to need to find a way to nuke the old ones. Now I'm
> saved by the fact that I can move all the planned Inline logic into
> C::MM which doesn't (and won't) have legacy problems.

Hmm, seems like the same thing can just happen with CPAN::MM later, 
though.

> See Ken? We shoulda spent more time talking and less time having fun at 
> OSCon
> ;)
>

I tend not to plan things very well in person, though, which generally 
makes me useless face-to-face. ;-)

  -Ken