Bug #29829 for File-ShareDir: FIles installed to different location than reported by dist

Sun Oct 07 19:44:36 2007 claco [...] cpan.org - Ticket created

Subject:

FIles installed to different location than reported by dist_dir

I'm not sure if this is a ShareDir thing, a Module::Install thing, or a INST_AUTODIR thing. I'm on a fresh install of Ubuntu with perl 5.8.8 and just did an install of Mango, which installs template files in ShareDir: ## Makefile.PL: install_share; When my app loads and calls ShareDir::dist_dir, it yields: /usr/local/lib/perl/5.8.8/auto/Mango This directory is empty. Instead, all of the files were installed into: /usr/local/share/perl/5.8.8/auto ShareDir::dist_dir returns /usr/local/lib/perl/5.8.8/auto/Mango ShareDir::module_dir returns /usr/local/share/perl/5.8.8/auto To make matters more confusing, M::Install::Share says: # Put everything inside ./share/ into the distribution 'auto' path Yet files are going into the local share, not the dist share as returns by dist_share later. I'm confused, and not sure what to do. I could use module_dir...but I have no idea if that is always going to be true either. Here's my perl -V --- Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=linux, osvers=2.6.15.7, archname=i486-linux-gnu-thread-multi uname='linux palmer 2.6.15.7 #1 smp thu sep 7 19:42:20 utc 2006 i686 gnulinux ' config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=i486-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.8 -Darchlib=/usr/lib/perl/5.8 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.8.8 -Dsitearch=/usr/local/lib/perl/5.8.8 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Uusenm -Duseshrplib -Dlibperl=libperl.so.5.8.8 -Dd_dosuid -des' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include' ccversion='', gccversion='4.1.3 20070831 (prerelease) (Ubuntu 4.1.2-16ubuntu1)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt perllibs=-ldl -lm -lpthread -lc -lcrypt libc=/lib/libc-2.6.1.so, so=so, useshrplib=true, libperl=libperl.so.5.8.8 gnulibc_version='2.6.1' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP THREADS_HAVE_PIDS USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API Built under linux Compiled at Sep 29 2007 05:57:38 @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 .

Wed Oct 31 05:27:56 2007 cpan [...] fireartist.com - Correspondence added

I've got a similar problem. Using Module::Install's install_share(), my files are installed in: /home/cafranks/local/lib/perl5/site_perl/5.8.8/auto/HTML/FormFu However, File::ShareDir's dist_dir() returns: /home/cafranks/local/lib/perl5/site_perl/5.8.8/i686-linux/auto/HTML/FormFu This is because the .packlist file is created in the 'i686-linux' directory - and because that's the first path in my @INC, it gets found first. I believe a practical work-around will be to use File::ShareDir's dist_file() method to locate a known file, and then use File::Spec's splitpath() to retrieve the directory from that. A suitable fix (for me, anyway) would be to change the file test in dist_file() from "-f" to "-e", so that it can be used to locate directories, not just files. I'm running perl 5.8.8, built from source, on Fedora Core 7 linux. My @INC is: $ perl -le 'print for @INC' /home/cafranks/local/lib/perl5/5.8.8/i686-linux /home/cafranks/local/lib/perl5/5.8.8 /home/cafranks/local/lib/perl5/site_perl/5.8.8/i686-linux /home/cafranks/local/lib/perl5/site_perl/5.8.8 /home/cafranks/local/lib/perl5/site_perl

Wed Oct 31 05:28:21 2007 The RT System itself - Status changed from 'new' to 'open'

Thu Oct 06 10:25:24 2011 ZENOG [...] cpan.org - Correspondence added

possibly related Padre bug: http://padre.perlide.org/trac/ticket/1327

Wed Nov 02 16:48:20 2011 KENTNL [...] cpan.org - Requestor KENTNL added

Wed Nov 02 16:59:02 2011 KENTNL [...] cpan.org - Correspondence added

I just bumped into what appears to be a variant of this bug, not sure if it counts as the *same* bug, but it certainly looks like it.

The problem appears to be, that there are paths that "look like" a valid sharedir path as it walks @INC, but contain nothing in them.

For a good way to replicate this:

1. Find a package with a sharedir that is already installed on your system via system perls ( ie: debian )
2. Install that same package with a local::lib ( creating ~/.perl/lib/ .... /auto/SOMETHINGHERE )

3. Remove that local::lib copy by rm'ing all the files listed in that distributions packlist.

This leaves behind a fully valid sharedir path, but with no valid entries in it, so this "empty" directory shadows the system version, even though the system version of that module is now in use.

The "real solution" is of course to not have empty cruft dirs, but when you do have these empty cruft dirs, it can be difficult working out that is the problem.

I propose a good step to progress would be some way of excluding dirs in @INC that are empty, but I guess this poses its own problems that I can't see being resolved without the distdir command taking an options hash. ( Ie: what about people who *want* the empty directory, what if people want a directory to be deemed empty if and only if there are no files matching a given regex, etc etc, what about directories that are empty bar one sub-directory, which is also empty? etc. )

Wed Nov 02 22:22:03 2011 adam [...] ali.as - Correspondence added

Subject:	Re: [rt.cpan.org #29829] FIles installed to different location than reported by dist_dir
Date:	Thu, 3 Nov 2011 13:21:51 +1100
To:	bug-File-ShareDir [...] rt.cpan.org
From:	Adam Kennedy <adamkennedybackup [...] gmail.com>

Share dir is storage for install-time readonly files, there is no reason whatsoever that you should have an empty one. Even the test modules with notionally empty sharedirs put a dummy file in it. I'll add a check for "any files at all" in this directory. Adam On 3 November 2011 07:59, Kent Fredric via RT <bug-File-ShareDir@rt.cpan.org> wrote: Show quoted text

> Queue: File-ShareDir > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=29829 > > > I just bumped into what appears to be a variant of this bug, not sure if it > counts as the *same* bug, but it certainly looks like it. > > The problem appears to be, that there are paths that "look like" a valid > sharedir path as it walks @INC, but contain nothing in them. > > For a good way to replicate this: > > 1. Find a package with a sharedir that is already installed on your system via > system perls ( ie: debian ) > 2. Install that same package with a local::lib ( creating ~/.perl/lib/ .... > /auto/SOMETHINGHERE ) > > 3. Remove that local::lib copy by rm'ing all the files listed in that > distributions packlist. > > This leaves behind a fully valid sharedir path, but with no valid entries in > it, so this "empty" directory shadows the system version, even though the > system version of that module is now in use. > > The "real solution" is of course to not have empty cruft dirs, but when you do > have these empty cruft dirs, it can be difficult working out that is the > problem. > > I propose a good step to progress would be some way of excluding dirs in @INC > that are empty, but I guess this poses its own problems that I can't see being > resolved without the distdir command taking an options hash. ( Ie: what about > people who *want* the empty directory, what if people want a directory to be > deemed empty if and only if there are no files matching a given regex, etc etc, > what about directories that are empty bar one sub-directory, which is also > empty? etc. ) > >

Sat Jun 09 12:19:28 2018 REHSACK [...] cpan.org - Correspondence added

If there is still a problem in File::ShareDir - not in Module:Install or File:.ShareDir::Install - please reopen with a clear and understandable description what's going wrong.

Sat Jun 09 12:19:29 2018 REHSACK [...] cpan.org - Status changed from 'open' to 'rejected'

Bug #29829 for File-ShareDir: FIles installed to different location than reported by dist_dir