andk / pause Goto Github PK

Perl 5.16 allows Unicode package names. While we can't have Unicode package names map to .pm files, an ASCII .pm file could contain Unicode "package NAME" statements.

Should Unicode package names be detected and indexed?

Statements like the following aren't properly parsed:

package Foo::Bar {
     …
}

Because of a quirk of the regex, specifying a version like the below does work:

package Foo::Bar 0.01 {
     …
}

BUT, the version you specify isn't picked up if there's a $VERSION declaration elsewhere in the file (even in a different package). See TSIBLEY/CPAN-Test-Dummy-Perl5-PackageWithBlock-0.01 and -0.03 for an example. The emails showing the incorrect index results are below.

The following report has been written by the PAUSE namespace indexer.
  Please contact [email protected] if there are any open questions.

  User: TSIBLEY (Thomas Sibley)
  Distribution file: CPAN-Test-Dummy-Perl5-PackageWithBlock-0.01.tar.gz
  Number of files: 12
  *.pm files: 1
  README: CPAN-Test-Dummy-Perl5-PackageWithBlock-0.01/README
  META-File: CPAN-Test-Dummy-Perl5-PackageWithBlock-0.01/META.json
  META-Parser: Parse::CPAN::Meta 1.4404
  META-driven index: no
  Timestamp of file: Wed May  8 21:05:20 2013 UTC
  Time of this run: Wed May  8 21:06:57 2013 UTC

Status of this distro: OK
=========================

The following packages (grouped by status) have been found in the distro:

Status: Successfully indexed
          ============================

     module: CPAN::Test::Dummy::Perl5::PackageWithBlock::AndVersion
          version: 0.01
          in file: CPAN-Test-Dummy-Perl5-PackageWithBlock-0.01/lib/CPAN/Test/Dummy/Perl5/PackageWithBlock.pm
          status: indexed

__END__

The following report has been written by the PAUSE namespace indexer.
  Please contact [email protected] if there are any open questions.

  User: TSIBLEY (Thomas Sibley)
  Distribution file: CPAN-Test-Dummy-Perl5-PackageWithBlock-0.03.tar.gz
  Number of files: 12
  *.pm files: 1
  README: CPAN-Test-Dummy-Perl5-PackageWithBlock-0.03/README
  META-File: CPAN-Test-Dummy-Perl5-PackageWithBlock-0.03/META.json
  META-Parser: Parse::CPAN::Meta 1.4404
  META-driven index: no
  Timestamp of file: Wed May  8 21:20:29 2013 UTC
  Time of this run: Wed May  8 21:22:11 2013 UTC

Status of this distro: OK
=========================

The following packages (grouped by status) have been found in the distro:

Status: Successfully indexed
          ============================

     module: CPAN::Test::Dummy::Perl5::PackageWithBlock::AndVersion
          version: 0.03
          in file: CPAN-Test-Dummy-Perl5-PackageWithBlock-0.03/lib/CPAN/Test/Dummy/Perl5/PackageWithBlock.pm
          status: indexed

__END__

There's code like this in PAUSE::dist:

my $binary_dist;
# ftp://ftp.funet.fi/pub/CPAN/modules/05bindist.convention.html
$binary_dist = 1 if $dist =~ /\d-bin-\d+-/i;

That 05 file is long gone, it seems. I think this behavior is also long dead.

This issue is to remind me (rjbs) to kill off the code path.

This issue follows up on message <[email protected]> from May 19, 2013.

A few items from perll-5.18.0 were not properly indexed.

 module: File::stat                                                       
      version: 1.07                                                       
      in file: perl-5.18.0/lib/File/stat.pm                               
      status: Not indexed because File-Stat-0.01/Stat.pm seems to have a  

This is a mistake that would be disallowed by the new case sensitivity.
File::Stat and File-Stat should be stricken from the index.

 module: Pod::Html                                                        
      version: 1.18                                                       
      in file: perl-5.18.0/ext/Pod-Html/lib/Pod/Html.pm                   
      status: Not indexed because PodSimplify-0.04/Pod/HTML.pm seems to   

This is the same situation: Pod::Html is widely installed and part of core.
This dist contains Pod::HTML and has not been updated since 1996. It should be
deindexed.

 module: deprecate                                                        
      version: 0.02                                                       
      in file: perl-5.18.0/lib/deprecate.pm                               
      status: Not indexed because lib/DEPRECATE.pm seems to have a dual   

Same thing: deprecate v. DEPRECATE.

https://metacpan.org/source/ETHER/Acme-Pi-3/lib/Acme/Pi.pm#L15 has:

my $version = atan2(1,1) * 4; $Acme::Pi::VERSION = "$version";

But the reply from PAUSE said:

Status: Successfully indexed
          ============================

     module: Acme::Pi
          version: undef
          in file: Acme-Pi-3/lib/Acme/Pi.pm
          status: indexed

As referenced in the email quoted in issue #75, PAUSE pulled this line out to use as the version:

if ($Bio::Root::Version::VERSION >= $version) {

I think the regexps in lib/PAUSE/pmfile.pm should be tightened.

The idea is that this information can then be used by tools (MetaCPAN, neilb's adoption list, etc.) for some useful purpose.

The "tags" I'm currently thinking about are:

• distinguish between individual and group (e.g. RATL, JUNIPER and SIXAPART are companies, as are CTI, CONNECTED, DATABUILT, DDG, FASTLY, and many others)
• indicate when an author has passed away (currently only SCHOP, AMORETTE , SPOON, NI-S have a "PAUSE Custodial Account" note in the name, but there are others. I also have no idea what the status of SAVA is.)

I have no idea what the technical solution can be. The special ADOPTME trick (make this account a co-main to indicate adoptability) works for modules, but won't for authors.

Obviously, the whole point of this is to make the information easy to query, possibly via the text files already part of CPAN. (Or maybe a new file?)

It looks as though this file is only updated once/day, which causes some issues with MetaCPAN and also CPANPLUS. From a conversation in #toolchain:

[09:10:16]  <oalders>    how often does authors/00whois.xml get updated?
[09:13:15]  <@BinGOs>    once a day?
[09:13:38]  <@BinGOs>    I hadn't updated my mirror since yesterday.
[09:13:49]  <@BinGOs>    $ ls -l /usr/home/ftp/CPAN/authors/00whois.xml
[09:13:49]  <@BinGOs>    -rw-r--r--  1 root  451  2443010 Jun 24 07:59 /usr/home/ftp/CPAN/authors/00whois.xml
[09:14:05]  <@BinGOs>    after updating:
[09:14:06]  <@BinGOs>    $ ls -l /usr/home/ftp/CPAN/authors/00whois.xml
[09:14:07]  <@BinGOs>    -rw-r--r--  1 root  451  2444153 Jun 25 07:59 /usr/home/ftp/CPAN/authors/00whois.xml
[09:14:18]  <oalders>    ah, ok
[09:14:32]  <oalders>    we're just seeing an issue on metacpan when a new author uploads something immediately
[09:14:35]  <@BinGOs>    observable extrapolation
[09:14:39]  <oalders>    :)
[09:14:51]  <oalders>    we get the upload, but we don't have the author information
[09:14:59]  <oalders>    https://metacpan.org/author/REZNIKOV
[09:15:01]  <oalders>    404
[09:15:10]  <oalders>    https://metacpan.org/release/REZNIKOV/Async-Chain-0.04
[09:15:12]  <+dipsy>     [ Async-Chain-0.04 - The right way to convert nested callback in plain struct or just - metacpan.org ]
[09:15:24]  <@BinGOs>    yeah, that can happen, as the authors data is on a slower cycle.
[09:15:57]  <@BinGOs>    I see it in CPANPLUS when it doesn't have the author data for something that is indexed in packages.
[09:16:26]  <oalders>    right. would be a similar issue. i wonder if we could get a faster update cycle
[09:17:03]  <@BinGOs>    andreas or other PAUSE contributers would be the right people to poke.
[09:18:09]  <@BinGOs>    oh, I just looked at the content of that whois.xml file. Huge clue at the top
[09:18:14]  <@BinGOs>    "generated-by='/home/puppet/pause/cron/cron-daily.pl'>"

Re http://www.nntp.perl.org/group/perl.modules/2013/05/msg85885.html --

Is there any way we can make PAUSE not think that this code means it should attempt to index a 'string' package?

https://metacpan.org/source/ETHER/Package-Variant-1.001004/lib/Package/Variant.pm#L34

Can we use something like Module::Metadata to parse the .pm to extract 'package' keywords?

For a number of my projects (the particular one prompting this request is the CPAN Dashboard) I'd really like a PAUSE-generated index that contains the latest release of all dists on CPAN, and where the latest is a developer release, then also include the latest stable release.

This might be something like the following (path, epoch-based upload time, size)

JHI/Graph-0.96.tar.gz 1369483123 147629
NEILB/Graph-0.96_01.tar.gz 1394362358 147335

Or perhaps should include a JSON fragment with package info:

NEILB/enum-1.06.tar.gz 1390608724 7230 [{'enum': '1.06'}]

More mulling can be seen in this gist.

In addition to case-folded indexing, finding "package Foo" in file "foo.pm" is probably an error and the user should be warned.

We could do that always or only if no other matching package is found. (So "package foo; package Foo" in foo.pm would be OK.)

Today's package file has these errors in version numbers:

Apache::mod_pml VERSION
DBIx::Class::Fixtures::SchemaVersioned set-when-loading
Device::Gsm::Charset Revision
Mail::SpamAssassin::Conf bogus
Mail::SpamAssassin::Dns bogus
Mail::SpamAssassin::Plugin bogus
Mail::SpamAssassin::PluginHandler bogus
Mail::SpamAssassin::Reporter bogus
Net::Download::Queue::Download Net
Net::Download::Queue::DownloadStatus Net
PML::Storable VERSION
SMS::Handler::Blackhole Revision
SMS::Handler::Dispatcher Revision
SMS::Handler::Email Revision
SMS::Handler::Invoke Revision
SMS::Handler::Ping Revision
SMS::Handler::Utils Revision
SMS::Handler::Utils Revision

$ curl --verbose -X HEAD http://www.cpan.org/modules/02packages.details.txt.gz
* About to connect() to www.cpan.org port 80 (#0)
*   Trying 199.15.176.140...
* Adding handle: conn: 0x100824800
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x100824800) send_pipe: 1, recv_pipe: 0
* Connected to www.cpan.org (199.15.176.140) port 80 (#0)
> HEAD /modules/02packages.details.txt.gz HTTP/1.1
> User-Agent: curl/7.30.0
> Host: www.cpan.org
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Sun, 26 May 2013 23:22:08 GMT
* Server Apache/2.2.3 (CentOS) is not blacklisted
< Server: Apache/2.2.3 (CentOS)
< Last-Modified: Sun, 26 May 2013 23:13:33 GMT
< ETag: "108b248-15a028-4dda72e4e4140"
< Accept-Ranges: bytes
< Content-Length: 1417256
< Content-Type: application/x-gzip
< 
* transfer closed with 1417256 bytes remaining to read
* Closing connection 0
curl: (18) transfer closed with 1417256 bytes remaining to read

It looks like the server still wants to send a body (so the client terminates
the connection "early"). Since many files served by PAUSE are large, there
would be an efficiency benefit by handling HEAD requests specially, by not
even bothering to prepare the file for transfer.

Passwords are hashed with crypt, which is -- in this day and age -- extremely insecure.

It should be replaced with bcrypt and some sort of upgrade procedure should be put in place to auto-upgrade passwords to bcrypt hashing when users log in.

For users that don't log in regularly, we should consider whether simply to invalidate their passwords in some way that avoids a brute force attack but allows a user to recover and set a bcrypt hashed password.

There have been two distributions uploaded recently that ended up in PAUSE using only the version number. One of these, https://metacpan.org/release/MLARUE/0.1_02, the author confirmed that he uploaded by URL from the Github release tag. I suspect the other did the same.

The URL given by github looks like https://github.com/mlarue/Cryptoki/archive/0.1_04.tar.gz but (after some redirects) includes a Content-Disposition header with filename=Cryptoki-0.1_04.tar.gz. It seems like PAUSE should respect these headers when naming the file on CPAN.

It would be useful to see mldistwatch log results either in the daemon tail file or another log file.

Per http://www.nntp.perl.org/group/perl.modules/2014/03/msg89623.html, Convert-Pluggable uploads are getting denied for lack of dist name permissions, but it contains new packages of the correct name. The tarball is odd, with development files (e.g. blib) included, but I don't know if that's related. I've answered his email with some explanation.

I think this means any perl upload could stomp on the indexing of something on CPAN.

Worth looking into

Distribution containing a /blib directory are usually made by CPAN beginners that did a tar.gz of their working directory instead of using make dist.
PAUSE should reject such distributions.

Here is an example of such mistake: http://api.metacpan.org/source/GIDEON/Dancer-Plugin-Auth-Github-0.01/

If successful, I don't really need to read the rest of the email: a list of successes isn't that interesting. If not successful, I want it to shout at me to fix the crap.

We include this:

md5: 20cbecd4e9e880ee7a50a136c8b1484e

...but "new perl" announcements give SHA1 sum. We should include that in the email.

I received a failed indexer report for dmake-4.12.2-20140329-SHAY.zip at Sat Mar 29 20:35:10 2014 UTC saying "This distribution name can only be used by users with permission for the package dmake, which you do not have."

Can anyone explain why this upload has failed to index?

I have uploaded binary builds of the dmake program (used by MinGW/gcc users to build perl and CPAN modules) numerous times before and never had this trouble. According to peek_perms it's not a case of someone else owning 'dmake' now, although I don't seem to own it either:

https://pause.perl.org/pause/authenquery?pause99_peek_perms_by=me&pause99_peek_perms_query=dmake&pause99_peek_perms_sub=Submit
says 'No records found.'

Perl's own README.win32 references the CPAN upload of dmake:

http://perl5.git.perl.org/perl.git/blob/HEAD:/README.win32#l107

so it would be nice to be able to upload a new version.

Andreas has suggested that perhaps it was never indexed (and doesn't need to be since it isn't a module) but never previously emailed to say so, so all I'm seeing here is improved error reporting.

However, previous versions have appeared on http://search.cpan.org, e.g.:

http://search.cpan.org/~shay/dmake-4.12-20090907-SHAY/

whereas my latest upload has not appeared at all.

What do I (now) need to do to make this possible for me?

Status: Permission missing
          ==========================

     module: Carp::REPL
          version: 0.16
          in file: Carp-REPL-0.16/lib/Carp/REPL.pm
          status: Not indexed because permission missing. Current registered
             primary maintainer is Carp::REPL. Hint: you can always find
             the legitimate maintainer(s) on PAUSE under "View
             Permissions".

Note that "Carp::REPL" is reported as the primary maint, not SARTAK.

The most likely looking change that could cause this is 02e8280, which switched the return value from list to scalar.

Once a new release is uploaded and indexed by PAUSE, an e-mail is sent to the author.
It would be useful to add to this e-mail some links that may be useful to the author to follow the life of his module.
This could help the new (and not so new) CPAN authors to discover those tools.

• a link to the CPANTesters page : http://www.cpantesters.org/distro/...
• a link to the CPANTesters matrix : http://matrix.cpantesters.org/?dist=...
• a link to the Kwalitee report at http://cpants.charsbar.org/dist/kwalitee/...

There are some authors with enormous uploads. E.g. KAL with distributions topping 150 MB.

While we do want to allow authors general freedom to upload what they want to their directories, we should consider limiting the size of uploads or the total size of an authors directory, just like other cloud data services do.

Distributions that need large data tables or .jar files should be downloading them from the web during build-time.

placeholder for this thorny issue: http://blogs.perl.org/users/neilb/2013/02/pause-permissions-should-be-case-insensitive.html

We should check email addresses in the PAUSE ID request form with Email::Valid (or equivalent), particularly including the domain name.

Invalid emails are a problem because welcome/password emails will bounce. They may also be a sign of a bot/spam attack.

I'm trying to figure how Apache2::RequestRec (from mod_perl-2.0.8) got into the 02packages index. The distribution does not contain a file named Apache2/RequestRec.pm nor is any such package listed in the META.

However, there is an Apache2::RequestRec package declared in a DummyVersions.pm file. This code suggests that if a package has ever been a simile in the past, then PAUSE will always put it in the index, even if it the package name doesn't actually match the file name any more. But I looked through BackPAN and could not find any authorized release containing a real (i.e. simile) Apache2::RequestRec module.

So I'm stumped. Can you help me understand what PAUSE is doing here?

Thanks!

Saašha Metsärantala [email protected] reported a PAUSE XHTML validation error for http://pause.perl.org/pause/query?ACTION=request_id (message at http://www.nntp.perl.org/group/perl.modules/2014/01/msg88720.html)

http://validator.w3.org/check?uri=http%3a%2f%2fpause.perl.org%2fpause%2fquery%3fACTION%3drequest_id

Line 51, Column 34: document type does not allow element "div" here; missing one of "object", "applet", "map", "iframe", "button", "ins", "del" start-tag

When PAUSE "have rewritten tarball to eliminate world writeables", the new tarball that it creates contains a directory entry for "./". This causes errors and security worries when untarring: see CPAN RT#83084. The output tarball should only contain an entry for directories beneath the current directory, not for the current directory itself.

I haven't received an email following a PAUSE upload in about a week. Is something amiss?

The three day delay for deletions is sometimes highly inconvenient - e.g. when dealing with an upload that was a mistake. It would be very helpful to have an option to immediately delete an upload -- it could be limited to one that was uploaded in the last hour, to prevent FYIQ-type abuses.

That would also greatly reduce the amount of personal involvement andk needs to take in sorting out indexing problems. :)

It would be great to have some more descriptive information on authors available directly in CPAN. We've been trying to tackle that with MetaCPAN, but there has been some discussion about the possibility of uploading an author.json file. Could you have a look at the comments on this article to see if it's something which is feasible?

http://blogs.perl.org/users/olaf_alders/2010/12/expanding-your-author-info-in-the-metacpan.html

If it's not unreasonable, I could see about finding someone to come up with a patch.

I'd like to have an additional field in the 02packages.details.txt.gz file that reflects the mtime of the distribution file (or perhaps the module file). My reason is this...

Given the indexes from two different repositories, I need to determine which one contains the latest version of any given package. If the version numbers are different, the only way to decide is based on the mtime of either the distribution or the module. As I understand the code, this is how PAUSE decides what the "latest" is.

Most code that parses the index files will probably just ignore an extra field (after the dist path). So hopefully, this change will be relatively safe.

What do you think?

This should probably be changed to /TRIAL$/: https://github.com/andk/pause/blob/master/lib/PAUSE/dist.pm#L254

As I read the code, for a new upload, any failure to add permissions for the primary package will cause NO_DISTNAME_PERMISSIONS to be set. However, in the mail summary, NO_DISTNAME_PERMISSIONS is checked first and shortcuts other error messages.

Put differently, NO_DISTNAME_PERMISSIONS is one of the last things to be checked during analysis, but is the first and only condition reported.

I think this might be obscuring messages about what actual errors are occurring.

I just visited https://pause.perl.org/pause/authenquery?ACTION=reindex and picked from the offered file names two that matched the dev release pattern. Pause let me do this and pretended this would lead to a reindexing. But as a matter of fact nothing will happen because they are dev releases. Bad UX.

Thanks to Dave Rolsky for bringing this to my attention.

This abstract comes from h2xs boilerplate and shows that the distribution has no valuable documentation.

Here is an example: https://metacpan.org/release/ASPerl

This is a meta-ticket for work related to retiring module registration.

From the Annotated Lancaster Consensus:

Module registration

The group agreed that the PAUSE module registration has largely
outlived its usefulness. Because only a fraction of CPAN modules are
registered, registration does not provide a comprehensive source of
metadata (e.g.  "DSLIP") and much of the information registration
covers is more widely available via META files.

    One benefit if module registration is that the data can be
    changed without requiring a new release the way META files do.
    On reflection, about the only field that matters for is the
    "support level".

The group acknowledged the remaining benefit has been that new CPAN
authors often attempt to register their first module and benefit
from feedback, but felt that other venues, such as PrePAN, would
offer a better new author experience. In particular, PrePAN offers
community participation beyond one or two PAUSE admins and a wealth
of examples to learn from (without having to search through a
mailing list archive).

    brian d foy has been the module registration hero, tirelessly
    responding to requests for years. PrePAN will help share the
    burden and new authors will benefit from different points of
    view.

Therefore, we agreed that existing PAUSE documentation will be
changed to direct new (and experienced) authors to PrePAN for
guidance.

Soon, PAUSE will stop publishing the module registration database to
CPAN mirrors. (The index file will exist but be empty to avoid
breaking CPAN clients that expect it.) After an assessment period,
module registration will likely be closed and this feature will be
retired from PAUSE.

It would be handy to warn when private packages collide with indexed ones.

This will often be "planned" when something is monkey-patching on purpose, but warning might help people detect and diagnose surprises.

The warning would need to wind up in the email about the result of indexing

The whole approach of -withoutworldwriteables seems wrong to me (and others I've discussed it with). It adds complication and confusion.

It also seems broken in that http://search.cpan.org/~pythian/DBD-Oracle-1.25/ shows both distro files, but wget -q -O - http://cpan.cpantesters.org/modules/02packages.details.txt.gz | zgrep 'DBD::Oracle ' only shows 0.24.

I believe it would be better to reject the tarball with message that explained the problem(s) and described how to fix them, including links to tools/utilities etc. (such as http://www.perlmonks.org/?node_id=731935) ?

Alternatively I'd support recognition of a class of "broken tarballs" and automatic in-place editing of permissions (like the script in http://www.perlmonks.org/?node_id=731935). Such tarballs are easy to recognize because the first entry is "drw-rw-rw-" which is clearly broken.

Tim.

Why does 02packages.details.txt contain these entries for the bignum distro?:

bigint 0.32 F/FL/FLORA/bignum-0.32.tar.gz
bignum 0.32 F/FL/FLORA/bignum-0.32.tar.gz
bigrat 0.32 F/FL/FLORA/bignum-0.32.tar.gz
Math::BigFloat::Trace 0.36 P/PJ/PJACKLAM/bignum-0.37.tar.gz
Math::BigInt::Trace 0.36 P/PJ/PJACKLAM/bignum-0.37.tar.gz

Specifically, why are the first three packages listed as in FLORA's 0.32 distro rather than PJACKLAM's 0.37 distro?

Both distros contain all five packages (and no others), and all five package $VERSIONs are bumped in 0.37 compared to 0.32.

At https://github.com/andk/pause/blob/master/lib/PAUSE/pmfile.pm#L41 there is a workaround ( cough hack cough ) that allows mod_perl to use a magical version.pm file to declare all the packages in the distribution. I'm sure it seemed reasonable at the time, but this seems way too subtle and one-off for the long term.

Could we remove that workaround and steer the mod_perl guys toward using a more normal means of package discovery (preferably, by declaring the provides field in the META)?

That last : isn't doubled.

context below.

In summary, user error between two maintainers of a dist resulted in two distributions being uploaded with the same version. While this is allowed by current PAUSE rules, and it is not on the table for this to change immediately, I think it would be useful to the user if PAUSE identified potential erroneous uploads with an informational message about repeated uploads with the same version number. This is sometimes intentional, but often not, so providing this information lets the user correct the situation if there indeed was an error.

original problem report:
http://www.nntp.perl.org/group/perl.modules/2013/05/msg86181.html

09:46 <xdg> What's up?
09:54  * xdg is going to lunch.  But email me whatever you need and I'll check 
          later.
11:16 <ether> sorry, very busy here too.  I was just wanting to touch base 
              briefly about the PAUSE indexing issue since it seemed we were 
              talking past each other
11:16 <ether> you seemed to be saying both "yes it's a good idea (to allow 
              different authors to upload the same dist name), and you're crazy 
              if you don't see that", and also "this is the way it is now, but 
              we'd like to change it"
11:17 <ether> which is somewhat contradictory
11:17 <ether> the question I was actually asking was "is this behaviour 
              intentional"
11:17 <ether> to which it sounds like the answer is "regrettably yes (but this 
              might change in the future)"
11:18 <ether> I guess the corollary to my question would be "is this behaviour 
              documented, and where"
11:30 <ether> but I mind the lack of docs less if there is a genuine desire, 
              coupled with tuit allocation, to fix the crazy
11:31 <ether> (I can help, too, if I understand what is needed)
12:19 <xdg> I'm back.  You around?
12:20 <xdg> I think I was trying to explain both "here's what it does now" and 
            "here's why".
12:24 <xdg> the "can't upload same file" is documented in "About PAUSE".  I 
            don't see the "versions must be non-decreasing" part documented 
            anywhere, so that might be just tribal knowledge.
12:26 <xdg> Back to "policy", I can't think of a good way to allow different 
            authors to upload the same file in some cases but not others.
12:27 <xdg> In your particular local::lib case, you had a maintainer failure, 
            and I think that needs to be dealt in human terms.
12:28 <xdg> My old company talked about "culture vs controls".  I think you (or 
            mst, I guess) need to consider how to treat a cultural breakdown.
12:30 <xdg> Separately, if local::lib used dzil for managing releases (even 
            with its own custom Makefile.PL) then it would be easier to 
            automate checking for dirty files or ensuring a tag/push happening 
            on release
12:47 <ether> here
12:47 <ether> yes, the local::lib problem was clearly human error
12:48 <ether> (I blame that we were using M::I for that dist, rather than dzil, 
              as my normal set of plugins both push after release, and also 
              check the remote for unpulled commits before release) :)
12:48 <ether> Distar also has both things in its flow too
12:49 <ether> but that aside, both apeiron and I were surprised that the 
              "duplicate" upload was allowed without error
12:49 <ether> it might have been useful if PAUSE had said something about this 
              in its email response, just as a heads up
12:50 <ether> "indexed local::lib 1.23; NOTE previous indexed version (uploaded 
              2013-02-xx via APEIRON/local-lib-1.23.tar.gz) also at version 
              1.23"
12:50 <ether> that would have clued me into there being an error
12:51 <ether> i.e. "we allow this, but maybe it's not what you wanted"
12:52 <ether> with your permission, I'd like to share this discussion with 
              apeiron, and whoever else expresses interest in the current PAUSE 
              situation?
12:55 <ether> which might just mean "pasted into a PAUSE ticket I haven't yet 
              filed"
13:21 <xdg> I see no problem with a "whoa, maybe this was an error" warning 
            from PAUSE, but I'm not sure the right heuristics.
13:22 <xdg> I'd open a ticket and hilight @dagolden and @rjbs and we can debate 
            heuristics there
13:26 <ether> may I include this conversation as context?
13:27 <xdg> sure

@xdg @rjbs @apeiron

it would be great if we could have common code used by PAUSE and by the module builders (EU::MM, M::B, M::I, D:;Z, etc.)

Would need a lot of testing to be confident in the switch.

Why do these two packages of the same distribution file return different versions?

➜  ~  curl http://cpanmetadb.plackperl.org/v1.0/package/Bio::Root::Version

---
distfile: C/CJ/CJFIELDS/BioPerl-1.6.923.tar.gz
version: 1.006923
➜  ~  curl http://cpanmetadb.plackperl.org/v1.0/package/Bio::Perl         

---
distfile: C/CJ/CJFIELDS/BioPerl-1.6.922.tar.gz
version: 1.006922

See
http://search.cpan.org/~cjfields/BioPerl-1.6.923/Bio/Perl.pm
http://search.cpan.org/~cjfields/BioPerl-1.6.923/Bio/Root/Version.pm

Today I received a request from MSCHILLI and GAAS to enable MSCHILLI to upload a libwww-perl-6.06 and get it indexed. On Michael's first attempt Pause had rejected the upload with the famous

    This distribution name can only be used by
    users with permission for the
    package libwww::perl, which you do not have.

Indeed Gisle had no chance to pass Michael the permissions for the imaginary libwww::perl because they only exist in the comaint-relevant table ("perms").

As a quick workaround I gave Michael the perms manually and hope that the indexer will pick it up correctly.

mysql> insert into perms (package,userid) values ('libwww::perl','MSCHILLI');
Query OK, 1 row affected (0.00 sec)

The question is: how do we want the workflow to work for grandfathered package and new comaintainers. The manual approach is not attractive. Add them all to primeur? Enforce a change of the name is a bit too brutal for my taste. I'm unsure whether there are more options I'm currently not thinking of.

Thanks,

Some modules in 02packages have version numbers that fail the "lax" criteria. E.g.:

Mail::SpamAssassin::Dns           bogus  K/KM/KMCGRAIL/Mail-SpamAssassin-3.3.2.tar.gz

Anything that can't be parsed by version->parse should be rejected, not indexed, as otherwise various guarantees (e.g. non-decreasing version numbers) can not be guaranteed.

We should probably purge from 02packages (and the underlying table) any such examples.

META v2 has 'release_status'. If this exists and is not 'stable' then the distribution should NOT be indexed.

[Fixed per ether's comment]