in reply to Re: ExtUtils::Installed doesn't list all modules
in thread ExtUtils::Installed doesn't list all modules
Thanks for the insights. I have been digging a bit further.
... and IMHO these two vars need to be joined by a third var, $Config{vendorarchexp}. That's a flaw in the module under almost any reasonable scope of expectations that I can conjure in my mind. However, it is not unreasonable that these two existing Config vars are used as they are, and this use is not limiting the scope of the search in exactly the manner explained by the OP. The reason for examing only FOOarchexp is that the values associated with each are the locations under which .packlist files are found.
The .packlist files (familiar to those of us who watch the actions of module installers (ExtUtils::MM, Module::Build) closely) were installed when each module was added to the Perl installation. ExtUtils::Installed is using the presence of these .packlist files as a means to the end of listing what modules have been installed.
Firstly, I don't see a config parameter called vendorarchexp. I am using the perl packaged with Debian. Maybe vendorarchexp is only set when perl has been built with vendor specifics. Here's the tail of my Config.pm:
tie %Config, 'Config', { archlibexp => '/usr/lib/perl/5.8', archname => 'i486-linux-gnu-thread-multi', cc => 'cc', d_readlink => 'define', d_symlink => 'define', dlsrc => 'dl_dlopen.xs', dont_use_nlink => undef, exe_ext => '', inc_version_list => '5.8.7 5.8.6 5.8.4 5.8.3 5.8.2 5.8.1 5.8.0', intsize => '4', ldlibpthname => 'LD_LIBRARY_PATH', libpth => '/usr/local/lib /lib /usr/lib', osname => 'linux', osvers => '2.6.15-1-686', path_sep => ':', privlibexp => '/usr/share/perl/5.8', scriptdir => '/usr/bin', sitearchexp => '/usr/local/lib/perl/5.8.8', sitelibexp => '/usr/local/share/perl/5.8.8', useithreads => 'define', usevendorprefix => 'define', version => '5.8.8', };
Secondly, I can think of several use cases where .packlist files are living elsewhere. The one that is biting me here is that I am on a system which has had its Perl version upgraded. The machine was originally Debian Sarge, which comes with 5.8.4, and is now Etch, with 5.8.8. Here's my @INC:
/etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl /usr/local/lib/perl/5.8.4 /usr/local/share/perl/5.8.4
And I find that my .packlists are evenly divided between being under /usr/local/lib/perl/5.8.4 and /usr/local/lib/perl/5.8.8. I don't believe I have a broken perl installation.
Consider the user installing modules not as root. They don't have write permissions to any of the perl lib directories, so they set PERL5LIB and install to their own private directory tree, packlists and all. This is the scenario for me at work; I am a developer, not a sysadmin.
Finally, it occurs to me that the packlists might not be giving the whole picture, even if we are picking up all of them. We know that current versions of ExtUtils::MakeMaker and Module::Build respect and honour packlists, but Module::Build has only done this relatively recently. I've also found cases of Module::Build installs where the module author has hijacked the install mechanism, and there's no packlist in sight. And, what's to say about other package management schemes. ActiveState PPM probably respects packlists, but I believe it's up to the module packager for Debian dpkg, Redhat RPM, yum, etc. to include the .packlist (or not, as might be the case).
--
Oh Lord, won’t you burn me a Knoppix CD ?
My friends all rate Windows, I must disagree.
Your powers of persuasion will set them all free,
So oh Lord, won’t you burn me a Knoppix CD ?
(Missquoting Janis Joplin)
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^3: ExtUtils::Installed doesn't list all modules
by Intrepid (Deacon) on Sep 25, 2006 at 09:35 UTC | |
Re^3: ExtUtils::Installed doesn't list all modules
by ysth (Canon) on Sep 26, 2006 at 10:17 UTC |