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