develooper Front page | perl.perl5.porters | Postings from July 2009

ExtUtils::Installed, and well, just exactly what are .packlists for?

Thread Next
July 19, 2009 03:58
ExtUtils::Installed, and well, just exactly what are .packlists for?
Message ID:
Hi Alan,

Recently I've been trying to chase down some bug reports related to

The bugs have to do with ExtUtils::Installed not searching all the
places where a module may have been installed.

So for instance, originally it never respected PERL5LIB. That was
changed some time back. But further warts have appeared.

The thing I dont get is when I check the full change history it never
paid any attention to the vendorlib/vendorlibexp locations, possibly
because it predates them i guess, but even then it only searched the
directories of archlib (now archlibexp), and sitearch (now
sitearchexp), and once it found them it then searched @INC to find
whatever was included. This leaves out of the packlist search any
possible -Mlib settings, as well as the PERL5LIB and other ways to
provide site customized lib paths (like and
$ENV{PERL5OPT}). Is this just an omission or is it intended?

The original patch looked like this (for those with git try: git log
--reverse -p lib/ExtUtils/

+# Read the module packlists
+my $sub = sub
+   {
+   # Only process module .packlists
+   return if ($_) ne ".packlist" || $File::Find::dir eq
+   # Hack of the leading bits of the paths & convert to a module name
+   my $module = $File::Find::name;
+   $module =~ s!$Config{archlib}/auto/(.*)/.packlist!$1!;
+   $module =~ s!$Config{sitearch}/auto/(.*)/.packlist!$1!;
+   my $modfile = "$";
+   $module =~ s!/!::!g;
+   # Find the top-level module file in @INC
+   $self->{$module}{version} = '';
+   foreach my $dir (@INC)
+      {
+      my $p = MM->catfile($dir, $modfile);
+      if (-f $p)
+         {
+         $self->{$module}{version} = MM->parse_version($p);
+         last;
+         }
+      }
+   # Read the .packlist
+   $self->{$module}{packlist} = ExtUtils::Packlist->new($File::Find::name);
+   };
+find($sub, $Config{archlib}, $Config{sitearch});
+return(bless($self, $class));

I don't get this at all. Why use archlib/sitearch in the find()
command, and not @INC?

It seems to me that using @INC alone makes more sense, especially
given that it is possible to install into many more locations than are
specified by the %Config. Can you or anybody else on list shed any
light on this?

Also, I have observerd that some distributors are NOT installing the
"$archlib/.packlist" file when they install perl. Should this be
considered "wrong" on behalf of the redistributors and should we
document that they SHOULD include .packlists in order to be properly
"compliant" in terms of distributing perl? Also should any RPM style
packaging systems also be educated to know about .packlists?

I can imagine a number of different scenarios:

1. ExtUtils::Installed is for "packages" that are installed via Perl
build processes, and CPAN or CPAN style tools. In this view
redistributions of such packages dont count, and as such should not
have .packlist files, as the purpose of the file is to tell the /perl/
packaging systems what was installed as part of a given package.
2. ExtUtils::Installed is for all modules that are installed, and is
simply not up to date with the many ways that they can be and needs to
be updated to take advantage of this fact.
3. Something else.

Appreciate any guidance you can provide. Im cc'ing a few people i
think might be relevant, sorry if you are already subscribed to p5p.


perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About