Skip Menu |
 

This queue is for tickets about the File-ShareDir CPAN distribution.

Report information
The Basics
Id: 29829
Status: open
Priority: 0/
Queue: File-ShareDir

People
Owner: Nobody in particular
Requestors: claco [...] cpan.org
KENTNL [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: 0.05
Fixed in: (no value)



Subject: FIles installed to different location than reported by dist_dir
Download (untitled) / with headers
text/plain 3.7k
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 .
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
possibly related Padre bug: http://padre.perlide.org/trac/ticket/1327
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. ) 
 

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>
Download (untitled) / with headers
text/plain 1.9k
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. ) > >


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.