.meta dir under site_lib w/ PERL_MM_OPT='INSTALL_DIRS=perl' #159

bowman opened this Issue Jun 13, 2012 · 3 comments


None yet
2 participants

bowman commented Jun 13, 2012

When INSTALL_DIRS is set to "perl" (or "vendor") the .meta directory used
is in the "site" directory, but probably should not be.

# relevant ENV
export PERL_MB_OPT='installdirs=core'

# where cpanm is (indirectly) installing modules w/ INSTALL_DIRS=perl
/usr/local/our/perl/lib/5.14.1  # $Config{privlibexp}

# where the .meta directory is placed

/usr/local/our/perl/lib/site_perl/5.14.1    # $Config{sitelibexp}

Background: the place I work at builds a perl and pre-installs a bunch of modules then bundles
everything up in a deb. The bundled modules are now installed with cpanm into the "core"|"perl"
directories ("site" is for the local system, "vendor" for our dependent .debs). This is all working well
and is much simpler than with the previous tools, the only minor exception is the .meta directory
being placed in the wrong set of directories. Ideally, the "site" directories would be squeaky clean.

It looks like the "install" happens at
with a $base set using $Config{sitelibexp} at
The code takes INSTALL_BASE into account, but not INSTALLDIRS.

I have a draft patch I'll link to, but it don't feel it is particularly neat.
Happy to clean it up or apply any suggestions, write test, etc.
I would like confirmation that this is something that would be considered worth following up.


bowman pushed a commit to bowman/cpanminus that referenced this issue Jun 13, 2012

Brad Bowman
.meta location w/ INSTALLDIRS=perl
now use $Config{privlibexp} and $Config{vendorlibexp} as the
base for the .meta director path.

An arch specific component $Config{archname} is still added to
the base for .meta (which assumes ${archlibexp} eq "${privlibexp}/${archname})

This patch assumes you're using either INSTALLDIRS or INSTALL_BASE
(it gives priority to INSTALL_BASE, which may be incorrect)

closes #159

bowman commented Jun 13, 2012

The draft fix:


Pull request also sent

bowman commented Jun 13, 2012

I should also note that I don't know what uses the .meta/{MYMETA.json,install.json}
information and so don't know if what I'm suggesting would break those tools.
I found it difficult to track down the details.


miyagawa commented Jun 13, 2012

.meta files are used by third party tools such as carton and pm-uninstall.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment