Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


"latest release" link points to unrelated distribution #797

dagolden opened this Issue · 13 comments

4 participants


Less critical than #796.

The "latest version" link points to which resolves to

But DAGOLDEN/Acme-CPAN-Testers-FAIL-0.02.tar.gz and BINGOS/Acme-CPAN-Testers-FAIL-0.02.tar.gz are unrelated distributions.

They share no modules. They share no maintainers.

They should not be linked in this way.


Would you rather see this feature go away for the 99% of cases where it works?
There is no way to detect the case you are making.


I'd agree, this is an edge case and not actually solvable other than removing the feature - which wouldn't be something we'd want to do.


I'm documenting that your data model is flawed. It works until it doesn't. What happens if some disgruntled Mooser releases unrelated Moose-666.tar.gz?

I've raised it here:

I've also put it on the agenda for the QA hackathon.

Hopefully, we'll find some resolution that doesn't mean you have to change your data model or rely on heuristics.


This is indeed an issue. /release/Moose would point to the latest release which would be Moose-666. For now, there is nothing that prevents that and metacpan is not alone with that issue (cpan testers will happily throw Moose-666 in the same bucket, right?).


Sort of. and various things have that problem, but the upstream data in at has the full AUTHOR/tarball path associated with reports. It's just not flowing downstream due to years of technical debt and lack of tuits.


I'm in favor of

(c)  We could restrict PAUSE to allow only "well formed" distribution
names[2] -- ones matching a module name inside containing a package of
a corresponding name.  E.g. "Foo-Bar", containing "Foo/" with
package "Foo::Bar".  The existing package permissions system becomes
the chokepoint to restrict abuse.  Existing distributions with
non-conforming names (e.g. libwww-perl) either change for their next
release or get grandfathered somehow.

Great write up!


Our primary key for releases is a hashed string of the author and the release name (including the version, excluding the tarball extension) which is unique.


from what i can see most of the other sites suffer the same issue (ratings, sco, etc)...
not that that's a valid reason to continue here, just that it's a pretty wide problem.


That's good. So worst case it might be a matter of having a heuristic mapping the non-unique distribution (and version) names to your unique hash in some reliable-ish way. E.g. once Moose only gets mapped to real Moose if the uploader has comaint on Moose.

Still, I hope I can convince people to let PAUSE enforce uniqueness in some way.


@rwstauner yes, it's a very wide issue. Fixing PAUSE means fixing just one place, but fixing it is seriously scary. The email thread I linked discusses some pros/cons of different approaches.

There's no good solution, just least worst solutions.


Closing as hasn't been actioned recently and ideally seems should be fixed in PAUSE instead of here

@ranguard ranguard closed this

This will not be fixed historically in PAUSE. It may eventually be fixed for future uploads.

As I said, MetaCPAN's data model is fundamentally flawed. If you're willing to live with that and not add any additional heuristics to work around it, then at least be honest about that instead of blaming PAUSE.



@dagolden "Fixing PAUSE means fixing just one place, but fixing it is seriously scary" - is why I said it seems should be fixed in PAUSE - thanks for the clarification

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.