I'm not sure why I missed those comments back in March until a kind soul flagged the package out-of-date half an hour ago. Sorry for that.

I've just added all the packages required for the optional REPL modules to the PKGBUILD. It's true that those modules are optional, but as they're distributed with the package the REPL attempts to auto-load them, which obviously fails is the optional modules' requirements aren't installed.

You'll have to install a couple more packages from the AUR now, but re.pl will start again.

After some testing:

Before compiling, add perl-lexical-persistence, perl-data-dump-streamer, and perl-ppi to the depends array in the PKGBUILD. lexical-persistence and data-dump-streamer are both AUR packages (with their own quirks that need some patching to the PKGBUILD.

This ensures that you are at the very least brought to the REPL shell (i.e., it runs), but I make no guarantees as to whether it parses Perl correctly after these additions~

Compiles just fine, but won't start.

% re.pl
Failed to load role: Devel::REPL::Plugin::LexEnv Can't locate Lexical/Persistence.pm in @INC (you may need to install the Lexical::Persistence module) (@INC contains: /usr/lib/perl5/5.30/site_perl /usr/share/perl5/site_perl /usr/lib/perl5/5.30/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5/5.30/core_perl /usr/share/perl5/core_perl) at /usr/share/perl5/vendor_perl/Devel/REPL/Plugin/LexEnv.pm line 10.
BEGIN failed--compilation aborted at /usr/share/perl5/vendor_perl/Devel/REPL/Plugin/LexEnv.pm line 10.
Compilation failed in require at /usr/share/perl5/vendor_perl/Module/Runtime.pm line 314.

The warnings while building perl-getopt-long-descriptive don't indicate that the package won't work. They only indicate that the package uses deprecated features that will be gone in Perl 5.32. You can simply build perl-getopt-long-descriptive without the tests, install it and continue with perl-moosex-getopt.

Additionally you should probably file a bug report with Getopt::Long::Descriptive.

Thanks for the tips, @mbunkus, I did as you prescribed.

When I reach step 4, it says that it wants perl-getopt-long-descriptive, which also fails testing.

I am aware of the Perl update. The problem is, as you've noticed, that its dependency perl-moosex-getopt doesn't test cleanly. A new version has already been released upstream that does compile, and perl-moosex-getopt has appropriately flagged as outdated.

So here's your solution:

1. Clone perl-moosex-getopt
2. Adjust its PKGBUILD to build 0.72 instead of 0.71
3. Install perl-test-needs, a new dependency of MooseX::Getopt 0.72
4. Build & install your modified perl-moosex-getopt
5. Build perl-devel-repl

I've just pushed a new version of perl-devel-repl that not only bumps the pkgrel, but also depends on perl-moosex-getopt>=0.72 in order to make this explicit.

ArchLinux Perl got updated from 5.26 to 5.28 recently, and as a result this package is b0rken.

pacman does not upgrade perl modules when a new base version is released, so to force a reinstall of all the modules, I run:

LC_ALL=C find "/usr/lib/perl5/site_perl" -type f -exec pacman -Qqo {} + |& sed -n 's/^error: No package owns \(.*\)$/\1/p'

as prescribed.

Some packages lag behind, such as perl-task-weaken and perl-getopt-long-descriptive. The former continues to install in /usr/lib/perl5/5.26 where as the latter just flatly fails to pass the testing phase.

Also, I made a comment for perl-data-dump-streamer which is one of the complaints re.pl fires at me when it starts. It seems to want this package even though it doesn't seem strictly necessary (I've gotten it to run without it).

The only solution right now is to pacman -Rccs perl-devel-repl and hope that some kind user can help me get it reinstalled. ;-)

Also, regarding my Jenkins builder, I'll Open Source it when it's ready. It will scan your aur4/ root for new dirs, changes to PKGBUILDs etc using Inotify and trigger builds, create new builds if a new directory appears in the root, delete builds when a dir is removed ( say deleted pkgbuilds etc ). That way, it'll help those of us with a cpl hundred thousand PKGBUILDs to stay ahead of problems. I hope to have it done before Perl 5.24 releases, since core perl always makes for funtimes for perlaur :-P Email me, or add me on FB and we'll coordinate testing etc.

Err, no, I'm very active with Maintainership of the AUR. I do rely heavily on the users to inform me when things break, even with an autobuilder, new deps can easily get missed, since I probably have hte dependency installed, but if the utility fails to catch the dep and put it in the pkgbuild, I'm ignorant to it, I only become aware of problems when either a) my build breaks or b) y'all tell me :D In other news, I'm working on a Jenkins build environment that will email me failures and can help me to notice problems a bit better, but even still, it won't be perfect. Just ping me if any of my PKGBUILDs are broken/out of date. I almost always get to them the same day I see the email.