Package Details: perl-moose 2.2207-2

Git Clone URL: https://aur.archlinux.org/perl-moose.git (read-only, click to copy)
Package Base: perl-moose
Description: A postmodern object system for Perl 5
Upstream URL: https://metacpan.org/release/Moose
Licenses: GPL, PerlArtistic
Submitter: None
Maintainer: Ordoban
Last Packager: Ordoban
Votes: 82
Popularity: 0.000089
First Submitted: 2009-04-20 16:45 (UTC)
Last Updated: 2024-09-05 06:06 (UTC)

Required by (119)

Sources (1)

Pinned Comments

jnbek commented on 2016-06-07 16:40 (UTC)

Ugh, even after the perl 5.24 upgrade, we're still getting errors in makepkg: Warning: prerequisite List::Util 1.45 not found. We have 1.4202. List::Util is a core module... we need this module to be version 1.45 before we can update this pkgbuild and it's millions of reverse-deps

Latest Comments

1 2 3 4 5 6 .. 11 Next › Last »

J5lx commented on 2022-06-07 18:53 (UTC)

.pod and .packlist files are disallowed by the Perl package guidelines and nowadays they can also automatically removed by turning on makepkg’s purge option. If you got packages with those files falsely detected by the ALPM hook, please notify the package maintainers so they can fix it.

Anyway, I agree with MarsSeed that empty pkgrel bumps are not particularly useful because of all the reasons they listed.

bidulock commented on 2022-06-07 10:50 (UTC)

@MarsSeed I disagree. Please continue to bump pkgrel on perl update that breaks dependency on libperl.so. perl package could fix this by providing libperl.so=5.38-64 or some such and then built binary packages could depend on the proper version of library to which the must link or they will not work.

The problem with the ALPM hook is that it does not even check what is in the directory. A .pod or a .packlist can cause it to trigger falsely.

MarsSeed commented on 2022-06-01 15:42 (UTC)

Hi,

Please don't do empty bumps of pkgrel next time. It makes sense when you control a binary repo, but the AUR is not a closed build system and the majority of its users are end-users doing their own builds (mostly via AUR helpers).

The [perl] package from Arch has a pacman ALPM hook that warns users if there are perl module files installed in a versioned directory that mismatches the system-installed Perl version.

Therefore the users will know if they need to manually rebuild their AUR-based Perl packages after an upstream [perl] package update.

Then, if you as an AUR package maintainer do this bump, such users have to do that rebuild a second time.

And no, it doesn't help even if you do the bump the same second Arch repo updates its Perl version: because there are downstream distros based on Arch Linux and the users of those can and do use the AUR as well. These downstream repos usually import Arch-built packages with some delay (Manjaro's most conservative stable branch usually has a delay of one month or more.)

For delayed downstream distros, your bump today will cause those distro users to do a superfluous rebuild with the earlier Perl 5.34, because they still have that version. Then, when their distros import the new Perl 5.36, those users still need to rebuild this AUR package manually .

I hope you understand the pain I am expressing on behalf of the average AUR user (who are quite large in number), and decide to accommodate all of us next time by not doing another changeless pkgrel bump.

Thank you.

chowbok commented on 2021-09-07 04:00 (UTC)

Can you add "aarch64" to the supported architectures? It builds fine on there.

bidulock commented on 2021-05-30 06:54 (UTC)

Package contains ELF files and must not be an "any" package.

bidulock commented on 2020-03-26 07:20 (UTC)

Package contains ELF files and must not be an "any" package.

jthvai commented on 2020-01-12 14:01 (UTC)

perl-module-runtime-conflicts should probably be added to the dependency list, as pacman will refuse to build this package without it.

J5lx commented on 2018-10-17 13:00 (UTC)

As bidulock wrote a while ago, the architecture of this package should not be any since it contains native code. Instead, supported architectures should be explicitly named (i.e. x86_64).

plaxx commented on 2018-08-09 18:44 (UTC)

You need to bump perl-devel-overloadinfo to perl-devel-overloadinfo>=0.005

dracorp commented on 2017-06-20 17:32 (UTC) (edited on 2017-06-20 17:54 (UTC) by dracorp)

And with perl-5.26.0-1: xs/Moose.c: loadable library and perl binaries are mismatched (got handshake key 0xdb80080, needed 0xde00080) on Makefile.PL -> check_conflicts() edit: After adding to PKGBUILD: sed '16s/^/#/' -i Makefile.PL I can install and use this module. How good is it?