Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#13808 - [perl] binaries in /usr/bin/perlbin/core do not follow FHS guidelines

Attached to Project: Arch Linux
Opened by Abhishek Dasgupta (abhidg) - Sunday, 15 March 2009, 06:09 GMT
Last edited by Kevin Piche (kpiche) - Monday, 08 November 2010, 04:20 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Kevin Piche (kpiche)
Francois Charette (Firmicus)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

The package perl (5.10.0-4) installs binaries in /usr/bin/perlbin/core
which is against the FHS guidelines [1]. According to FHS, the only allowed
subdirectory of /usr/bin is /usr/bin/mh.

The fix is to change -Dscriptdir to '/usr/bin'

[1]: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRBINMOSTUSERCOMMANDS
This task depends upon

Closed by  Kevin Piche (kpiche)
Monday, 08 November 2010, 04:20 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in perl 5.12.2-1
Comment by Francois Charette (Firmicus) - Thursday, 28 May 2009, 23:29 GMT
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?
Comment by Gerardo Exequiel Pozzi (djgera) - Friday, 29 January 2010, 21:56 GMT
any decision on this?
Comment by Kevin Piche (kpiche) - Saturday, 08 May 2010, 01:26 GMT
I'm implementing Francois' suggestion in perl 5.12.0.
Comment by Kevin Piche (kpiche) - Sunday, 09 May 2010, 03:52 GMT
Note that offending perlbin directories will continue to exist until affected packages are rebuild.
Comment by Dan McGee (toofishes) - Wednesday, 12 May 2010, 23:10 GMT
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.
Comment by Dan McGee (toofishes) - Wednesday, 12 May 2010, 23:14 GMT
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.
Comment by Dan McGee (toofishes) - Wednesday, 12 May 2010, 23:16 GMT
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
Comment by Kevin Piche (kpiche) - Thursday, 13 May 2010, 03:45 GMT
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.
Comment by Caleb Cushing (xenoterracide) - Saturday, 17 July 2010, 07:52 GMT
  • Field changed: Percent Complete (100% → 0%)
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.
Comment by Caleb Cushing (xenoterracide) - Saturday, 17 July 2010, 08:08 GMT
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...
Comment by Francois Charette (Firmicus) - Saturday, 17 July 2010, 13:28 GMT
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?
Comment by Caleb Cushing (xenoterracide) - Saturday, 17 July 2010, 21:55 GMT
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.
Comment by Francois Charette (Firmicus) - Monday, 19 July 2010, 07:22 GMT
> 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.
Comment by Kevin Piche (kpiche) - Monday, 08 November 2010, 02:45 GMT
Perl 5.12.2 will use the /usr/bin/*_perl directories as scriptdirs.

Loading...