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

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

From:
Ken Williams
Date:
March 26, 2003 16:22
Subject:
Re: rfc: a generic solution for dual-life CPAN packages
Message ID:
1DFEBFEA-5FEA-11D7-A9E2-003065F6D85A@mathforum.org

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 CPAN.pm 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?]

>
> 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.


> 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.

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?".

> Back to our particular problem.
>
> We want to minimize the dependencies to zero, so a user downloading 
> mod_perl already has all the critical packages. The reason I want to 
> redistribute some of these packages separately on CPAN is for mod_perl 
> 1.0 users, so they can download these packages without needing to 
> install mod_perl 2.0.

That sounds reasonable.


> 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.

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.

> 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.

  -Ken




nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About