develooper Front page | perl.perl5.porters | Postings from March 2003

Re: rfc: a generic solution for dual-life CPAN packages

Stas Bekman
March 26, 2003 16:48
Re: rfc: a generic solution for dual-life CPAN packages
Message ID:
Ken Williams wrote:
> On Wednesday, March 26, 2003, at 06:01  PM, Stas Bekman wrote:
>> As Andreas correctly points out, it's the indexer thing, not the 
>> client or CPANPLUS. So this change is transparent to users 
>> having whatever version of CPAN/CPANPLUS they have.
> I see.  [I think I missed Andreas' message on module-authors, maybe it 
> was only to p5p?]

Nope, he did post to both lists.

>> First of all this is a more generic problem than in my particular 
>> case, we already have this problem with all packages living in the 
>> core and separately on the CPAN. The indexer introduces a special case 
>> for perl core.
> For what it's worth, my solution to that problem would essentially be 
> the same as what I recommended in your case: for core modules that are 
> in CPAN independently, the core should essentially "depend" on the CPAN 
> versions.

But it doesn't. Since we want the core to include all the essential modules in 
the core. If downloading the dependant modules was a trivial thing, the core 
would simply include them, right?

>> Now think of the mod_perl distro, as the perl core distro, do we 
>> introduce a special case here? And if tomorrow a new big distro needs 
>> this functionality, do they ask for a special case as well? That's too 
>> much of a hassle for Andreas IMHO.
> So it looks like the issue is that we want a way for a module to appear 
> in more than one distribution.  From a packaging (dpkg, etc.) 
> standpoint, I think this is often solved by saying that a particular 
> package "provides" a particular functionality.  For instance, several 
> different packages may provide a mailer.  But what do you do if you want 
> to install a mailer but you don't know which package to get it from?  
> I'm not sure this case is usually handled.  The user usually has to 
> choose manually.

True, but in this we also have the master package which includes only that 
thing and nothing else.

> Ideally, I think, CPAN or CPANPLUS would tell the user "the requested 
> module is available in the following distributions, which one do you 
> want to install?".

True, but the user might not be aware which one is the right one. And if the 
server side (the indexer) can provide a non-ambiguous solution in first place, 
why delegating this to a client, which may be outdated.

>> In particular we have the Apache::Test suite which lives in the 
>> mod_perl 2.0 source distro, but since it also works with mod_perl 1.0 
>> or any Apache module (C/Perl/PHP/etc), it should have its own life on 
>> CPAN.
> And you're proposing that the CPAN version is the primary one, right?


> Inevitably there will be version sync issues, unless you release a new 
> mod_perl every time its bundled modules are released.  For example, will 
> it be possible for a user who already has, say, Apache::Test 0.14 
> installed to download and install mod_perl, which includes Apache::Test 
> 0.12, without backporting?  And does this lock you into endless rigid 
> backward compatibility?  It seems like it does.

For a moment I thought you caught me, but luckily it's not a problem in this 
particular case. However it can be a problem in other cases.

First of all, perl-core already suffers from this problem. If I install the 
latest Test::Harness and then upgrade perl, chances are that I downgrade 
Test::Harness, right?

Second, both Apache::Test and ModPerl::MMHelper (or whatever I'll call it) 
aren't modules for the end user. The two are needed during the module 
build/test time. So there is absolutely no problem with the version number. If 
it's the core build, it already includes a version that it builds and tests 
with just right. If it's a 3rd party Apache:: module, its PREREQ_PM will 
specify the wanted versions of Apache::Test and ModPerl::MMHelper which user 
has to satisfy.

> I'm not trying to poo-poo the idea, but I do think it introduces some 
> complexities that aren't present in a simple X-depends-on-Y and 
> Y-is-only-provided-by-distro-FOO model.

In general case, possible. In my case it doesn't.

I just still too vividly remember the agony of getting perl 5.6 fetched and 
built when you want to install some module for perl 5.005_03 ;)

>> While we can suggest using CPAN::MakeMaker for the latter case, since 
>> this module is going to be small. Apache::Test is a big package (50k 
>> tar.gz) and bundling it with every Apache:: CPAN package would be a 
>> waste of space and bandwidth.
> I tend to think that CPAN::MakeMaker introduces the same kinds of 
> problems I've outlined above.

That's correct. Perhaps its doc could add a warning, since I'm sure many 
people won't think about it (just like I didn't ;)

Thanks Ken.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide ---> Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About