On Sat, Oct 25, 2003 at 01:24:59PM +0800, Autrijus Tang wrote:
A) On the PAUSE side, it should publish data for all currently existing, distinct module versions under 02packages.details.txt.gz. So, where it currently has:
mod_perl 1.29 G/GO/GOZER/mod_perl-1.29.tar.gz
You'd like it to say:
... mod_perl 1.27 G/GO/GOZER/mod_perl-1.27.tar.gz mod_perl 1.28 G/GO/GOZER/mod_perl-1.28.tar.gz mod_perl 1.29 G/GO/GOZER/mod_perl-1.29.tar.gz mod_perl 2.00 S/ST/STAS/mod_perl-2.00.tar.gz ...
That will be a massive increase in data volume.
I think the index only needs to track "The highest of each major version for each author".
So you'd generate a new index entry only if the major version has changed or if the author of the new release is different to the author of the previous minor version of the same major version.
Here's an example sequence of uploads to demonstrate:
JOE 1.1 new entry JOE 1.2 replaces 1.1 entry JOE 1.3 replaces 1.2 entry JIM 2.0 new entry JIM 2.1 replaces 2.0 entry JOE 1.4 replaces 1.3 entry JIM 1.5 new entry
and you'd end up with these entries
JOE 1.4 JIM 1.5 JIM 2.1
Yes, but we need a more robust criteria for deciding when a generation was bumped up. I don't think it's possible to use just the major version number or the author switch for it. I suggest the following approach:
PAUSE indexer should:
1) support a new META.yml key:
generation
which the author will be responsible to bump up, when a new generation is started.
2) in case the author made a mistake and forgot to update META.yml or in case of packages that were already uploaded and therefore cannot provide this information, the indexer should provide some interface for fixing or adding this information.
So in most cases new packages with META.yml will tell the Indexer the information and the authors won't need to do anything special. For existing packages, the author needs to go to pause.cpan.org and assign to each existing version what generation it belongs to.
Once this phase is completed the indexer will be able to return the higher version number for each generation. So in case of GD.pm it could be:
1.27 1.45 2.10
(I don't remember now the real version numbers the interface was switched at).
Now, the client doesn't care about the generation number. All it wants is the above index. The client will now say:
PREREQ_PM => {
GD => [1.39, 1.46] # 1.39 <= ver < 1.46
}and from the above index 1.45 will be selected since it's the highest index which is 1.39 <= ver < 1.46.
The cool thing is that generation numbers are totally irrelevant and can be even called as strings or A, B, C, etc. So if the author decided to make another sub-generation he can just go and split things further, without affecting the clients that require this author's packages.
On the CPAN.pm/CPANPLUS side, doing:
cpan> install GD
should now present a selection choice:
1.27 1.45 2.10
with some configuration options to automatically pick the latest. Ideally META.yml should provide more information about each of the generations to help user make the right choice. So it'll look like:
Choose from:
1.27 - if you have libgd1.0 1.45 - if you have libgd2.0 and ... 2.10 - if you have libgd3.0 and ...
> B) Module::Install needs to implement Module::Build::Base's > check_installed_status and _parse_conditions subroutine, so it can parse > the more flexible version requirement, even faced with a legacy version > of ExtUtils::MakeMaker.
Yup, as per above examples. Another idea is that it can probably have a good guess which version to upgrade to. e.g if the user had GD 1.26 and now GD 1.27 is available (from the same generation, besides many other versions), asking CPAN.pm to suggest upgrade should suggest 1.27 as a preferred selection.
> Also, it should also allow the case that Apache::Foo having two distinct > versions on CPAN, one supporting mod_perl1 and one mod_perl2. > > A Module::Install::Apache extension should implement a way to detect and > install itself into sitelib/Apache2/Apache/Foo.pm. Maybe probing for > Apache2::mod_perl is enough to determine this.
Well, if as an author of Apache::Foo module you use ModPerl::MM::WriteMakefile it does it for you automatically. We need to write a mod_perl wrapper for Module::Build, but I'm not aware of Apache:: modules using it yet.
> ...so, did I understand you correctly? If that's all there needs to > happen, I'd invite you to investigate (and build on) Graham Barr's > Module::Install::InstallDirs for B). I'll see what I can do with A).
I gave some more input on A above, but in general more or less this is correct. As for B, once A is done there will be needed two tracks to take place:
CPAN/CPANPLUS/search.cpan.org clients need to start using this info.
MakeMaker/Module::Build should support the range of PREREQ_PM, in addition to a single number spec.
Of course in parallel, the authors will need to become aware that they need to tell PAUSE if they have generation setup.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
