Reject dists containing /blib
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/
Olivier Mengué [email protected] writes:
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/
Sorry, Olivier, I disagree. PAUSE should never reject anything on aesthetic reasons. Exceptions to the rule are security issues and law enforcement and when the community might be damaged or such.
Only two things are appropriate:
- write a bugreport
- a notification from the upload notifier that a blib directory was detected. This has been implemented a long time ago and so the uploader has received a notification that this distro is not indexed due to the slip.
And it seems that the latter was sufficient to alert the author and a 0.02 release happened soon after.
And this is perfectly as we want to have it. For early adopters the release is available, but for the convenience of all others it is not indexed.
andreas
I'll throw in my 2 cents on this...
I think PAUSE can and should reject a distribution for any reason it wants, so long as the criteria for rejection are well defined and documented. These criteria could include things like invalid meta, unauthorized packages, impolite tarballs, or world-writable file permissions.
PAUSE's liberal input policy places a burden on all the downstream tools to work around those problems. As the entry point to the CPAN ecosystem, PAUSE is uniquely positioned to filter bad inputs and maintain order in the Perl universe.
In Lancaster, Andreas clarified that PAUSE/CPAN is more in the model of Dropbox. Authors get a directory and can upload and organize what they wish. The "control" is over the index. So whenever anyone says "PAUSE should reject", what is meant is that "PAUSE must not index".
David Golden [email protected] writes:
In Lancaster, Andreas clarified that PAUSE/CPAN is more in the model of Dropbox.
A bit of a misunderstanding. CPAN is focused on perl, and not arbitrary like dropbox; it never was and never will be a place of arbitrary content. If we do not insist on having our focus, we cannot survive. There must be a line what is welcome and what is not welcome.
Authors get a directory and can upload and organize what they wish. The "control" is over the index. So whenever anyone says "PAUSE should reject", what is meant is that "PAUSE must not index".
This is correct. CPAN is not about censorship, but it is focused on perl ("the perl family"), and we do as much as we can to keep it focused. But not more. Indexing for QA.
andreas
On Thu, Apr 18, 2013 at 5:00 PM, andk [email protected] wrote:
A bit of a misunderstanding. CPAN is focused on perl, and not arbitrary like dropbox; it never was and never will be a place of arbitrary content. If we do not insist on having our focus, we cannot survive. There must be a line what is welcome and what is not welcome.
But we don't monitor it, so effectively, people can upload whatever they want. Once, at least. :-) * * *David *
"Censorship" isn't the word I would use here. I think of it more like "cooperation".
As the size and density of any ecosystem increases, the priorities inevitably change. If you live out in the rural countryside, you can dig wells and dump sewage wherever you want on your property. But if you live in the city, you must attach to the standard municipal services.
In the early days, the CPAN ecosystem was small, standards were weak, and there was less certainty about what the tool chain would look like. So back then, it made sense to keep the barriers low and encourage lots of creative thinking. But now, the ecosystem is much larger, the standards are stronger, and the tool chain is more sophisticated. At this point, the need for interoperability trumps the desire for freedom of expression.
Saying that the index is the quality control mechanism feels unsatisfactory to me. The index has a very narrow and time-dependent view of what CPAN is. We don't expect CPAN to merely provide us with arbitrary tarballs. Rather, we expect it to provide things that the tool chain knows what to do with. But if PAUSE lets anything in the front door, then every down stream tool has to implement the same hacks and workarounds to deal with the uncertain and ill-defined input they will receive from CPAN.
On Thu, Apr 18, 2013 at 6:20 PM, Jeffrey Ryan Thalhammer < [email protected]> wrote:
Saying that the index is the quality control mechanism feels unsatisfactory to me. The index has a very narrow and time-dependent view of what CPAN is. We don't expect CPAN to merely provide us with arbitrary tarballs. Rather, we expect it to provide things that the tool chain knows what to do with. But if PAUSE lets anything in the front door, then every down stream tool has to implement the same hacks and workarounds to deal with the uncertain and ill-defined input they will receive from CPAN.
My medium-term goal is to separate the concepts of indexes and mirrors. An index should be a mapping between package name and URLs (which could be URI::cpan style to indicate "any CPAN mirror"). Then CPAN and/or BackPAN become just repositories. We can have people competing to provide curated indices for any particular purpose and indices can be used to better decide what is "up to code" and what is not.
David
David Golden [email protected] Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg
This was fixed in the past.