On Tue, Oct 21, 2003 at 02:22:09PM -0700, Stas Bekman wrote: > Tim Bunce wrote: > [...] > > >To be honest, I think the only practical solution that could be > >implemented in time and be used by most people, is to ship both v1 > >and v2 versions of the module in each distribution. > > There are several problems with this approach: > > 1. what do you do if different versions are maintained by different authors
They could cooperate. > 2. each time v1 releases an update, users of v2 will be forced to update > even though their version hasn't changed. Yes. > 3. once the disto with both versions is downloaded users will still have to > choose which version to install. Meaning interaction with MakeMaker. Each > author will implement it differently leaving users with consistent > interface. Since that interaction (or some other env var, special options > to MakeMaker) are unavoidable, it's much better to implement on the > CPAN/MakeMaker client side which will enforce a consistent familiar > interface across all modules. The selection of which to build/install could be abstracted into a module that's a prerequisite for these combined distributions. > I'm sure we can come up with several other problems with this approach. Probably. I didn't say it was perfect, just the only practical solution I could see that would work in the short term for users who haven't/won't/can't upgrade their perl/CPAN code. > I was hoping that this issue will be discussed at the CPAN meeting, > apparently not much progress has been made :( I hope that you realize how > critical this feature to mod_perl 2 and all Apache:: modules, which are now > mostly delayed from being released for mod_perl 2.0 because of this problem. I do. > Also don't forget another related problem I brought up a few months ago on > p5p. Libraries like GD, have several reincarnations existing at the same > time. And it's left to the user the drill of manually going to cpan.org and > picking the right reincarnation, by wading through 50 or so readme files, > trying to figure out which is the right version to choose. I don't want to > mix this problem with the more critical issue discussed in this email, but > this is something that needs to be on the chart of the things that need to > be fixed. Solutions and patches welcome, from anyone. Tim.
