Hi Alan, Recently I've been trying to chase down some bug reports related to ExtUtils::Install. 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 sitecustomize.pl 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/Installed.pm) +# Read the module packlists +my $sub = sub + { + # Only process module .packlists + return if ($_) ne ".packlist" || $File::Find::dir eq $Config{installarchlib}; + + # 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.pm"; + $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. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Next