Arch Linux

Agreed. But this was not done just for fun: see
http://wiki.archlinux.org/index.php/Perl_Policy#Binaries_and_Scripts

Kevin: Should we put those under /usr/lib/perl5/{core,vendor,site}_perl/bin instead?

any decision on this?

I'm implementing Francois' suggestion in perl 5.12.0.

Note that offending perlbin directories will continue to exist until affected packages are rebuild.

This is busted for me. I think I lost every one of these binaries on upgrade. Here is a list from my untouched machine (5.10.1-5):
/usr/bin/perlbin/core:
c2ph cpanp-run-perl instmodsh piconv pod2usage ptar
config_data dprofpp libnetcfg pl2pm podchecker ptardiff
corelist enc2xs perlbug pod2html podselect s2p
cpan find2perl perldoc pod2latex prove shasum
cpan2dist h2ph perlivp pod2man psed splain
cpanp h2xs perlthanks pod2text pstruct xsubpp

If I take a `ls -1 /usr/bin/perlbin/core` and move it somewhere, it looks like this:

dmcgee@dublin ~
$ for bin in "pacman"; do find /usr/bin -name $bin; done
/usr/bin/pacman

dmcgee@dublin ~
$ for bin in $(cat /tmp/binaries.txt); do find /usr/bin -name $bin; done


I noticed this building a perl package that requires pod2man which is now absent.

Hmm. I think I'm just a dummy and didn't log out and log back in to get this stuff to pick up, that might explain it. That is a bit hard to do under screen, I'll get back to you.

It does set the path a bit odd and double :: ends up in there:
/bin:/usr/bin:/sbin:/usr/sbin::/usr/bin/perlbin/site:/usr/bin/perlbin/vendor:/usr/lib/perl5/core_perl/bin

It only adds the directories if they exist now and the double colon was reported in  FS#19411  and will be fixed in next pkgrel tomorrow.

looks like the ultimate solution is to put things in /usr/lib/perl5/vendor_perl/bin, etc. and where should a file go if its namespace is bin:: ? there are a few of those. I don't think there are currently anything that would conflict... I'm just saying, this may not be exceptionally future proof.

also having read that section of the FHS, I can't find (maybe I missed it?) anything that says you can't have other directories in /usr/bin only that mh is required if present. Maybe there's another better solution...

You're right! There is no statement that forbids having subdirs of /usr/bin: the FHS standard solely says that if mh is installed, then /usr/bin/mh/ must exist, which implicitly legitimates the existence of subdirs under /usr/bin ...
Kevin: should we not revert to the previous setup?

another option which might seem somewhat inconsistent would be

put core and vendor in
/usr/bin/

and define that all AUR pkgbuilds go in site_perl which will put them in
/usr/local/bin

(which would have to be before /usr/bin in PATH)

arch doesn't package updated versions of core pkgs so that should prevent conflicts in /usr/bin I would think.


another thing that problematic about putting them in /usr/lib FHS says this

"/usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts."

almost every binary (bin) that comes with a cpan module is intended to be executed by a script or user.

> put core and vendor in
> /usr/bin/
This is against the Arch policy: we allow packaging modules that are also provided by core (if a more recent version is required, for instance). So a (hypothetical) package "perl-cpanplus" in community would result in a conflict with /usr/bin/cpanp from core.

I think the previous setup was optimal. It works well and is very flexible.

Perl 5.12.2 will use the /usr/bin/*_perl directories as scriptdirs.