Re: Move dev release tarballs to GitHub?

[Todd Rinaldo via cpan-workers]

All,

I’m unclear who decides if it’s OK for me to delete the dev versions of Perl 
I’ve done. I’m happy to do it. Maybe we should put a policy or suggestion into 
the release manager’s guide as a first step?

Todd

On 4/5/22, 4:54 AM, "Ask Bjørn Hansen"  wrote:

That’d make sense to me, deleting the old images and letting them just be on 
backpan. That should allow whatever tooling depends on recent releases being in 
the regular CPAN mirrors to still work.

Looking at 3 days of www.cpan.org logs only the most 
recent development image seems to have been downloaded more than the background 
noise of everything getting a request now and then because web crawlers. (And 
the most recent development image by just number of downloads recently is less 
popular than about a dozen very old not-development releases).

I put a CSV of the counts of “perl5-“ URLs temporarily at 
https://tmp.askask.com/os/cpan/cpan-perl-downloads-2022-04-05-02_13_21.csv


Ask

Re: Confirming PAUSE operating model safe harbor for Alt::* distributions

[Todd Rinaldo]

> On Oct 26, 2017, at 11:04 PM, Salve J Nilsen  wrote:
> 
> David Golden said:
>> On Thu, Oct 26, 2017 at 11:29 AM, Chad Granum  wrote:
>> 
>>> I have a small objection to putting an alt module in a namespace other
>>> than alt: It is less obvious. If I see Alt::Thing I will simply know it
>>> will replace Thing.
>> 
>> Consider, too, if someone else wants to another alternative Thing.
>> Alt::Thing2 -- is that a second Alt::Thing?  Or an alternative of Thing2?
>> 
>> Possibly namespacing like Thing::Alt::Boring would then allow
>> Thing::Alt::Spiffy, etc.  But I don't want to have explicit rules about
>> this.  I think intent is more important.
> 
> Would adding a field to the META spec about API conformance solve some this?
> 
> api_conforms_to:
>   module: CPAN::Thing
>   version: 2.61
> 

As a packager, that would certainly make it easier. We've run into 2 cpan 
modules using the same file in the past and had to sort it out. This sort of 
information would be a very helpful thing we could check.

Todd



smime.p7s
Description: S/MIME cryptographic signature

Re: Supporting a perl without . in @INC

[Todd Rinaldo]

> On Jan 18, 2017, at 6:49 AM, James E Keenan <jk...@verizon.net> wrote:
> 
> On 01/16/2017 12:06 PM, Todd Rinaldo wrote:
>> All,
>> 
>> What at this point I feel is lacking is agreement and/or discussion that the 
>> above is the correct approach to solving this problem.
>> 
> 
> Well, since no one else has responded in this location, I will.
> 
> I suppose the first step would be to open bug tickets for each of the 
> distributions mentioned (github issue in the case of cpanminus).  So far, 
> this issue is referred to in only one ticket for CPAN.

I was asked to open a discussion rather than opening with the solution. 
However, 2 months of effort has yielded almost no response. I'll be opening the 
relevant tickets this weekend. 

>> If you are not for this plan and/or you are a maintainer of one of the above 
>> mentioned packages, your response would be appreciated. We're running out of 
>> time to complete this in time for perl 5.26.
>> 
> 
> Have you written, or do you need to have written, any program identifying 
> affected distributions on CPAN?
> 

Almost all Module::Install based modules will need to be fixed for sure with a 
minor change to Makefile.PL. Something along the lines of: 
perl -pi -e 's/(use inc::Module::Install;)/BEGIN{push \@INC, "."}\n$1/' 
Makefile.PL

Once the mentioned modules in my email are fixed, it was my hope we could 
simply flip the default bit on this feature in perl and let smokers reveal the 
scope of the remaining problem. I expect it to be 100-200 modules which will 
need a more hand crafted fix, though it may be more like 10-20.

Todd

Supporting a perl without . in @INC

[Todd Rinaldo]

All,

Currently in blead is a change that will begin breaking many CPAN installs. 
This is a result of a non-default change to perl builds which removes . from 
@INC. There is currently a separate proposal ( 
https://rt.perl.org/Public/Bug/Display.html?id=130467 
<https://rt.perl.org/Public/Bug/Display.html?id=130467> )being discussed to 
remove . from @INC by default in 5.26. 

More information on the impact of this can also be found here. 
http://blogs.perl.org/users/todd_rinaldo/2016/11/how-removing-from-inc-is-about-to-break-cpan.html
 
<http://blogs.perl.org/users/todd_rinaldo/2016/11/how-removing-from-inc-is-about-to-break-cpan.html>

As I understand things, this is the closest thing to a mailing list for the 
toolchain group, so I'm trying this list first.

In order to action RT 130467 without completely breaking CPAN, I propose the 
following patches to CPAN install related modules to fix the problem:

* Inject PERL_USE_UNSAFE_INC=1 into the environment early in the following 
clients. This assures that everything spawned by these clients gets . in @INC 
during test/install.
CPAN
CPANPLUS
App::cpanminus

* Inject PERL_USE_UNSAFE_INC=1 into TAP::Harness to support ad-hoc use of 
prove. (Leon is already working on this)

* Inject PERL_USE_UNSAFE_INC=1 into install modules to try to address as many 
Makefile.PL missing . in @INC issues as possible:
ExtUtils::MakeMaker
Module::Build
Module::Build::Tiny

What at this point I feel is lacking is agreement and/or discussion that the 
above is the correct approach to solving this problem. 

If you are not for this plan and/or you are a maintainer of one of the above 
mentioned packages, your response would be appreciated. We're running out of 
time to complete this in time for perl 5.26.

Thanks,
Todd Rinaldo

Re: Thoughts on Kik and NPM and implications for CPAN

[Todd Rinaldo]

> On Mar 23, 2016, at 11:20 AM, David Golden  wrote:
> 
> On Wed, Mar 23, 2016 at 11:25 AM, Stefan Seifert  > wrote:
> > * I think we have to allow mass deletion, even if that de-indexes stuff.  I
> > think that's an author's right.
> 
> I've never gotten that argument.
> 
> Let's try a narrower argument: Should an author be allowed to delete *any* 
> distribution?
> 
> * Old tarballs?  Seems reasonable.
> 
> * Currently indexed tarballs?  What if a file was included that was never 
> meant for publication?  What if there was a really dangerous bug?  What if it 
> was accidentally uploaded company code that *isn't* open source?
> 
> I can think of several legitimate reasons to allow deletion and de-indexing.
> 
> Moreover, if we disallowed deletion, an author could just upload an empty 
> module except for a higher version number and get that indexed and that is as 
> effective at breaking things as removal.
> 
> So given that removal (a) has several reasonable uses and (b) doesn't stop 
> authors from mass-breaking dependents if they want to, I see no reason to 
> prohibit it.
> 
> David

I agree with you taking away delete doesn't solve anything. So at best, all we 
can do is mitigate the catastrophes when they happen.

For me the scenario I worry about is: KWILLIAMS declares Module::Build a 
failure. He then removes all co-maints and wipes all of his tarballs. IMO, 
PAUSE admins should have a right to say: NOPE. Leon is now the owner of M::B, 
especially if the module removal breaks a large enough part of CPAN.

+1 to addressing https://github.com/andk/pause/issues/169 
. This is a potential security issue 
waiting to happen.

Todd