Front page | perl.perl5.porters |
Postings from March 2003
Re: rfc: a generic solution for dual-life CPAN packages
Thread Previous
|
Thread Next
From:
Stas Bekman
Date:
March 26, 2003 16:48
Subject:
Re: rfc: a generic solution for dual-life CPAN packages
Message ID:
3E8249F4.3020908@stason.org
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 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?]
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?
Yes.
> 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
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Thread Previous
|
Thread Next