Re: Move dev release tarballs to GitHub?

On Sun, Apr 10, 2022 at 5:44 PM Karen Etheridge wrote: > On Sun, Apr 10, 2022 at 6:43 AM Ricardo Signes < > perl.cpanw...@rjbs.manxome.org> wrote: > >> Looking good. "plenv install" finds the file at metacpan, which, it >> appears, is actually a backpan mirror. This suggests that we can safely

Re: Making www.cpan.org TLS-only

On Tue, Sep 5, 2017 at 6:34 AM, Ask Bjørn Hansen wrote: > > Among things that should allow non-TLS: I would include /src/. Also the > top-level RECENT files, things in /indices/. > > +1. > > Maybe it makes more sense to reverse the logic and just targeting whatever > the most

Re: No . in @INC breaks CPAN

On Mon, Nov 14, 2016 at 3:11 PM, Todd Rinaldo wrote: > Howdy, > > I've done a write up of a recent change to blead perl. In the future it > will no longer be possible to count on . being in @INC. This will break > many of the existing CPAN installs. > > It was suggested I send

Re: Renaming the "QA Hackathon"?

On Tue, Apr 19, 2016 at 12:33 PM, Salve J Nilsen wrote: > Well, good luck figuring out this topic! Wish I could join you in Rugby, > and I'm looking forward to hear where this discussion goes, and where the > 10th anniversiary will be next year. (On that note, would you guys be >

Re: Passing some torches

On Sun, Apr 3, 2016 at 12:32 PM, David Golden wrote: > I am -- and will remain -- primary maintainer of the following, but there > are no co-maintainers; I'd like someone(s) to volunteer to be my backup > (the work should be trivial): > > * Perl-OSType > * CPAN-Meta-YAML > I think

Re: Thoughts on Kik and NPM and implications for CPAN

On Wed, Mar 23, 2016 at 4:07 PM, David Golden wrote: > If you don't know what I'm referring to, read > http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ > > Leaving aside the IP issue, I think it might be worth considering what > would currently happen if someone chose a

Re: Why do we keep using META.json for stuff that has nothing to do with installation

On Sat, Feb 27, 2016 at 12:06 PM, Peter Rabbitson wrote: > Copying a rhetorical question from #distzilla here, as it warrants a wider > audience. The background is yet another discussion of a kludgy workaround > where an installation with an older JSON parser is tripped by

Re: Looking for prior art on conventions for dep-listing

On Tue, Mar 1, 2016 at 10:35 PM, Peter Rabbitson wrote: > I didn't phrase my question correctly. What I am after is: > > Imagine you get a random checkout of some dist and/or extract a tarball. > Aside from running `perl Makefile.PL` and visually checking what is > missing,

Re: Fwd: [ExtUtils-MakeMaker] the future of EUMM's development model(#242)

On Thu, Oct 29, 2015 at 11:13 PM, bulk88 wrote: Where is the list described in #2 for Perl-Toolchain-Gang controlled > modules? > The policy was decided, and I know it was implemented for some modules, but not necessarily on all yet. This is a goal, not an immediate reality.

Re: How To Build A Perl Package Database

On Sat, Jan 5, 2013 at 12:33 AM, Adam Kennedy a...@ali.as wrote: I'll say it a second time... Packlist 2.0 Take MYMETA, add an extra key with the list that will be installed, intall it in the usual place as we do now. Package manager scans the filesystem for the packlist files. Might

Re: How To Build A Perl Package Database

On Mon, Dec 31, 2012 at 6:50 PM, Jan Dubois j...@activestate.com wrote: Mostly I would prohibit sharing of directories between Perl installations, and even within a single installation, the sharing of directories between install locations. E.g. the default configuration right now has

Re: How To Build A Perl Package Database

On Fri, Dec 28, 2012 at 2:44 AM, Jan Dubois j...@activestate.com wrote: I wonder if it isn't time to deprecate all the complex install combinations that may have made sense when hard disks was rather limited. In ActivePerl we enforce a pretty simplified install layout to be able to create an

Re: How To Build A Perl Package Database

On Mon, Dec 17, 2012 at 9:36 AM, Tim Bunce tim.bu...@pobox.com wrote: A separate install database for each install location seems like the only workable approach. One minor complication of that is the strictest sense an install location isn't all that well defined. Or perhaps I should say every

Re: How To Build A Perl Package Database

On Sat, Dec 15, 2012 at 11:59 PM, Michael G Schwern schw...@pobox.com wrote: We have a lot of serious problems because we lack a database of installed distributions, releases and files. There are serious problems with implementing one given A) the limitations of the standard Perl install and

Re: How To Build A Perl Package Database

On Sun, Dec 16, 2012 at 6:34 PM, Johan Vromans jvrom...@squirrel.nl wrote: Debian, and most other systems have decent package- and install managers. *They* maintain the database with installed distributions, releases and files. The only good approach for us is to play with them. So, an

Re: How To Build A Perl Package Database

On Mon, Dec 17, 2012 at 1:53 AM, Michael G Schwern schw...@pobox.com wrote: I was thinking about what you said about packlists, and I wonder how much information one could scrape out of them. Would it be enough to reconstruct at least that a group of files belongs to a release? That would be

Re: For P::PT - ExtUtils::XBuilder

On Wed, Nov 21, 2012 at 12:20 PM, Jens Rehsack rehs...@gmail.com wrote: Well, I need control over the invoked executables and flags for specific languages - especially for integrating it into Config::AutoConf That is possible (though there may still be some edge cases in the autodetect logic

Re: For P::PT - ExtUtils::XBuilder

On Sun, Nov 18, 2012 at 8:41 PM, Jens Rehsack rehs...@gmail.com wrote: long time ago I wanted a ExtUtils::CBuilder successor. Leon started such a one, but it hasn't the features I needed for e.g. Proc::ProcessTable or Net::Radio::Location::SUPL::Test - so I started an own one - see

Introducing ExtUtils::Builder, a new compilation and linking toolkit

Hi all, As a few of you may already know, I've been working on a new compilation and linking toolkit, called ExtUtils::Builder. It's intended as a replacement for ExtUtils::CBuilder. ExtUtils::CBuilder has a number of issues that I'm running into: 1) The only thing it does reliably is creating

Fwd: [rt.cpan.org #78246] Install failure with CPAN.pm: Alert: no Build file available for 'make '

Hi cpan-workers, Can any of you make soup from this report? I have no idea what's going on, specially because «relaunching the install just after now works». I don't even know if this is an issue with Module::Build::Tiny or CPAN.pm. It doesn't help that I couldn't reproduce it. Anyone have a