Package Details: perl-authen-pam 0.16-11

Git Clone URL: (read-only, click to copy)
Package Base: perl-authen-pam
Description: Perl interface to PAM library
Upstream URL:
Licenses: GPL, PerlArtistic
Submitter: jose1711
Maintainer: jose1711 (amish)
Last Packager: amish
Votes: 12
Popularity: 0.000113
First Submitted: 2016-07-25 05:09 (UTC)
Last Updated: 2023-08-08 04:14 (UTC)

Latest Comments

1 2 3 Next › Last »

amish commented on 2022-06-02 00:55 (UTC)


Sorry when there is a re-build, logically there must be an increase in pkgrel because previous package and new package are not same anymore.

Arch is rolling release, it does not wait for those who still want to be on old perl.

Arch does not officially support any other distro like Manjaro.

That said I would say sorry that I do not agree with you here.

MarsSeed commented on 2022-06-01 16:11 (UTC)

I believe you should automate the rebuild on the client-side, e.g. using a simple custom pacman libalpm hook. With these empty bumps, you screw with those admins who already automated the necessary rebuilds, and with all the people who are on delayed downstream distros.

amish commented on 2022-06-01 15:58 (UTC) (edited on 2022-06-01 15:59 (UTC) by amish)

@MarsSeed I have 20+ servers using perl-authen-pam.

I have my own repository which serves packages that I maintain on AUR.

I can not go and manually install each perl package in each system.

Logically pkgrel must be updated if files or directories change. Because contents of old package and new package are no more same. And hence must have different versions. That is why versioning system and pkgrel system was designed. So that package manager (pacman in case of Arch Linux) knows that a new version is out and it should be installed.

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


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.

mr_nuub commented on 2018-12-12 08:44 (UTC) (edited on 2018-12-12 08:45 (UTC) by mr_nuub)

@jose1711 Sorry to bother you again, but you forgot to set INSTALLDIRS=vendor in the package() function. I don't know if this is required, though.

jose1711 commented on 2018-12-12 06:30 (UTC)

@amish how about i make you a comaintainer and you apply the suggested fixes yourself?

jose1711 commented on 2018-12-11 22:27 (UTC)

@mr_nuub seems i am seriously outdated. thanks, should be fixed now

mr_nuub commented on 2018-12-10 21:06 (UTC) (edited on 2018-12-10 21:14 (UTC) by mr_nuub)

@jose1711 Hi! Maybe you schould read I can't use webmin/usermin with this PKGBUILD, because it installs the modules to my users home directory.