Re: CPAN meeting: a few clarifications wanted
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 Tim.
Re: CPAN meeting: a few clarifications wanted
Tim Bunce wrote: On Sat, Oct 25, 2003 at 01:24:59PM +0800, Autrijus Tang wrote: Hmm, I've never received this email from Autrijus. Is it because you aren't subscribed and the email is hold by the moderator? Can you please repost it to me (the usual cpan.org address), so I can get the whole context before following up on this? Thanks. 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 __ Stas BekmanJAm_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
Re: CPAN meeting: a few clarifications wanted
?b 六, 2003-10-25 01:54, Stas Bekman ?g?D?G > > This is a significant issue for the community and so I'd hope > > someone would offer to help. The relative silence here is troubling. > > Perhaps it's the wrong list and/or we're the only people subscribed :( It appears that way. I have just attempted to subscribe to the list -- I erroneoously assumed that cplan people were automagically subscribed on cpan-discuss. Turns out not to be the case. Mmm, weird, sending stuff to [EMAIL PROTECTED] did not work. I'll try again later today. > Hmm, I've CC'ed Andreas and Autrijus, the two folks who can make the biggest > impact on resolving this issue in case they aren't on [EMAIL PROTECTED] > Andreas, Autrijus, what do you think about this issue? Let's see... I have read the nntp.perl.org archive now. Basically, you are asking for two things. 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 ... Because otherwise, tools like CPAN and CPANPLUS cannot satisfy the complex dependencies efficiently. 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. 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. ...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). Thanks, /Autrijus/ signature.asc Description: =?UTF-8?Q?=E9=80=99=E6=98=AF=E6=95=B8=E4=BD=8D=E5=8A=A0=E7=B0=BD?= =?UTF-8?Q?=E7=9A=84=E9=83=B5?= =?UTF-8?Q?=E4=BB=B6?=
Re: CPAN meeting: a few clarifications wanted
Tim Bunce wrote:
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.
MakeMak
Re: CPAN meeting: a few clarifications wanted
?b 六, 2003-10-25 18:27, Tim Bunce ?g?D?G > That will be a massive increase in data volume. I fail to see why. They are, after all, highly redundant and very gzippable. Also, users may freely specify version ranges that disallows minor versions, not only major ones. Maybe some sort of concrete numbers will be better. I'll see what I can do. Thanks, /Autrijus/ signature.asc Description: =?UTF-8?Q?=E9=80=99=E6=98=AF=E6=95=B8=E4=BD=8D=E5=8A=A0=E7=B0=BD?= =?UTF-8?Q?=E7=9A=84=E9=83=B5?= =?UTF-8?Q?=E4=BB=B6?=
