On Mon, Feb 17, 2014 at 7:04 PM, John D Jones III <unixgeek1972@gmail.com> wrote:

On 02/17/14 16:32, Jason St. John wrote:

...

Hello,

Is there any reason to keep AUR packages for Perl core modules? The only reason I can think of is if there is an important bug fix or feature addition that has not made it into the latest Perl release yet, but I'm guessing this doesn't happen very often.

Should _all_ AUR packages for Perl core modules be deleted or should only AUR packages where the latest version on CPAN is <= the provides list for the 'perl' package in [core] be deleted? If so, should I/we just send an email to this list, as usual, for all of these packages?

Jason

Jason: Well it depends on the core module. Certain ones like: CPANPLUS for instance as well as some of it's dependencies, warn loudly about CPANPLUS being removed from CORE in an up coming version of Perl and to install from CPAN. I have a few I maintain for that reason, so when that Perl version hits the Core repo, they're already there and won't break pplz code. These cases are cases where we want them there.

On the other hand, once a module that was not in CORE on older versions become CORE modules, I believe that the corresponding AUR Package should be removed. I've lamented a few times about packages like Catalyst::Runtime that complain about needing a newer module than what's available in CORE, I've debated seeing about submitting these new versions; the time or two I've tried, I've been staunchly rejected but the AUR uploader. Thankfully this is rare, and it's usually a module in Community, where one can just mark that package out of date.

I've tried to be vigilant about the CORE modules that are warning loudly about being removed from CORE and getting an AUR PKGBUILD up as quickly as possible; This is the only viable argument for CORE modz in AUR as far as I'm concerned.

-- Thanks, John D Jones III UNIX Zealot; Perl Lover unixgeek1972@gmail.com jnbek1972@gmail.com http://zoelife4u.org/

Is there a list published somewhere of the core modules that will be removed in upcoming versions of Perl? I have a small Perl script that can check a given module and its version, but if a list has already been made, that would be easier for me than hacking it to check the big list of provided modules from the perl package in [core]. Thanks, Jason

On 02/18/14 13:57, John D Jones III wrote:

On 02/17/14 23:19, Jason St. John wrote: Well to get the best results, one must scour the perldelta(.*) pages for upgraded/deprecated/removed modules

https://metacpan.org/pod/release/RJBS/perl-5.19.8/pod/perl5190delta.pod#Remo... shows the modz that

are due to be pulled in 5.19.0 there are others in the later perldeltas that are going into the deprecated list as well.

https://metacpan.org/pod/release/RJBS/perl-5.19.8/pod/perl5197delta.pod#Remo...

shows CGI.pm going into deprecated status,

https://metacpan.org/pod/release/RJBS/perl-5.19.8/pod/perl5196delta.pod#Depr... has some more as well. I'm not sure

how easy it'd be to script that, a

corelist --dif 5.18.0 5.19.0 | grep absent

Seems to be a good way to determine that, but it implies having 5.19.0 installed. Maybe we should have a perl-developer-release AUR package to simplify the process? though that could get messy with all the community modules that may depend on deprecated code from the developer-releases. Thoughts?

I stand corrected, corelist --dif 5.18.0 5.19.7 does in fact work on the current installed version of Perl from the Arch Core repo. And it shows those modules not in CORE Perl as of 5.18 that will be by 5.19.7, so that will be very easy to script :) -- Thanks, John D Jones III UNIX Zealot; Perl Lover unixgeek1972@gmail.com jnbek1972@gmail.com http://zoelife4u.org/