You are not logged in.

#1 2020-10-27 06:07:27

Registered: 2016-02-08
Posts: 262

rebuilding perl modules (chroot, private repo) ELI5

Arch Linux - News: Perl library path change
I read the news item above, but I have no experience with Perl and I don't know any coding details of the affected packages. I'm just learning about PKGBUILDs and private repos. I feel like this is a stupid question, but the situation left me confused. Even though it appears I resolved the issue, I'd like to clear up my confusion so I don't feel like I'm totally in the dark.

I want to know if the issue has anything to do with me building these AUR packages in a chroot and storing them in my private repo. I don't think it does, but that's part of my confusion.

The arch linux - Rebuild old Perl Modules page suggests just removing the affected packages and reinstalling from AUR, but in my case I installed the packages from a private repo. Removing and reinstalling did seem to be the solution for me.

Arch News says, "You must rebuild all affected packages against the new perl package before you can use them again." Since perl is intrepreted, what does "rebuild all affected packages" even mean? It seems to mean just reinstalling them. What does that do? Does it just move them to a different directory tree?

Here's the actual warning I saw on the device I updated today:

(2/3) Warn about old perl modules
WARNING: '/usr/lib/perl5/5.30' contains data from at least 2 packages which will NOT be used by the installed perl interpreter.
 -> Run the following command to get a list of affected packages: pacman -Qqo '/usr/lib/perl5/5.30'

# pacman -Qqo '/usr/lib/perl5/5.30'

In a comment on the Unix & Linux Stack Exchange page, jasonwryan says,

You reinstall them from the AUR, and hope that the maintainer has updated the PKGBUILDs to conform to the new library path. – jasonwryan Sep 8 '17 at 3:13

I looked at the PKGBUILD files and I don't see any references to a specific perl library path. Here's the PKGBUILD for one of the affected perl packages. What would I look for here? I assume the PKGBUILD is OK because removing and reinstalling this package solved the issue. So I just want to know what to look for in the future.

pkgdesc="Extend File::ShareDir to Local Libraries"
license=('PerlArtistic' 'GPL')

build() {
  ( export PERL_MM_USE_DEFAULT=1 PERL5LIB=""                 \
      PERL_AUTOINSTALL=--skipdeps                            \
      PERL_MM_OPT="INSTALLDIRS=vendor DESTDIR='$pkgdir'"     \
      PERL_MB_OPT="--installdirs vendor --destdir '$pkgdir'" \

    cd "$srcdir/$_distdir"
    /usr/bin/perl Makefile.PL

check() {
  cd "$srcdir/$_distdir"
    make test

package() {
  cd "$srcdir/$_distdir"
  make install
  find "$pkgdir" -name .packlist -o -name perllocal.pod -delete

Here's exactly what I did to eliminate the warning:

pacman -R hsxkpasswd perl-file-share
pacman -Syu hsxkpasswd perl-file-share
(2/3) Warn about old perl modules
(no output)

I'd like to know why that works.

Before doing that I had:

# pacman -Qqo '/usr/lib/perl5/5.30'
(just those 2 lines total)


# pacman -Qqo '/usr/lib/perl5/5.30'
error: No package owns /usr/lib/perl5/5.30

So removing and reinstalling moved that packages from 5.30 to 5.32.

However, the versions I had installed previously came from the AUR, and when I reinstalled, they came from my private repo. Does that have any bearing on this?

This is from Device #1 where I built the packages in a chroot. These commands were executed in the directory where I have the PKGBUILD from the AUR saved:

$ perl -V:vendorarch

$ perl -V:vendorarch

Do I need to make sure the perl version in the chroot matches the perl version on all target devices where my package will be installed?

Here are related links:


Board footer

Powered by FluxBB