| 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: | 83 |
| Popularity: | 0.006748 |
| First Submitted: | 2009-04-20 16:45 (UTC) |
| Last Updated: | 2024-01-21 06:41 (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.
@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.
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.
Can you add "aarch64" to the supported architectures? It builds fine on there.
Package contains ELF files and must not be an "any" package.
Package contains ELF files and must not be an "any" package.
perl-module-runtime-conflicts should probably be added to the dependency list, as pacman will refuse to build this package without it.
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).
You need to bump perl-devel-overloadinfo to perl-devel-overloadinfo>=0.005
Pinned Comments
jnbek commented on 2016-06-07 16:40 (UTC)