Opened 11 years ago

Last modified 8 years ago

#36980 new defect

perl5.x: sitebin & vendorbin flags may be inapproriate

Reported by: d-lamb (Derek Lamb) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: brucemiller (bruce miller), mojca (Mojca Miklavec)
Port: perl5

Description

In revision r94655, the flags sitebin and vendorbin were added, and point to ${prefix}/libexec/perl5.14/sitebin. But the GNU coding standards state that libexec is "The directory for installing executable programs to be run by other programs rather than by users." Thus any perl modules that produce a script or binary executable and don't override these defaults with an INSTALLSITEBIN=/opt/local/bin (for EU::MM modules) & INSTALLSITESCRIPT will write their executables to a directory that is probably not in their path. I'm not sure if that is the intended behavior that motivated that change, but thought I'd check.

In particular I was thinking of the Perl Data Language scripts & executables 'pdl', 'perldl', 'pdl2' & 'pdldoc', which ended up in libexec. But it may also be the case for modules. I also have a 're.pl' and a 'moose-outdated' in my libexec, which may be the correct location for them, I'm not sure.

Change History (16)

comment:1 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)

Owner: changed from macports-tickets@… to ricci@…

comment:2 Changed 11 years ago by jmroot (Joshua Root)

Yes, libexec isn't really the correct place. But they can't go in ${prefix}/bin because then different perl versions would conflict, as mentioned in the commit message. Version-suffixed links are placed in ${prefix}/bin.

comment:3 Changed 11 years ago by brucemiller (bruce miller)

I don't entirely understand that last comment. The perl scripts that are being installed will end up with a #! line pointing to whatever perl installed them, wont they?

I suppose it is nice to have a goal that multiple versions of perl could work, but the current result is that programs that use perl don't! :>

What is the workaround? How should we adapt our Makefile.PL so that it works on Macs as well as other systems? (putting an explicit /opt/local/bin, for example, is not a portable solution)

Thanks;

comment:4 Changed 11 years ago by brucemiller (bruce miller)

Cc: bruce.miller@… added

Cc Me!

comment:5 in reply to:  3 Changed 11 years ago by larryv (Lawrence Velázquez)

Replying to bruce.miller@…:

I don't entirely understand that last comment. The perl scripts that are being installed will end up with a #! line pointing to whatever perl installed them, wont they?

Yes, but p5.x-foo would still try to install the same executables as p5.y-foo and would thus conflict.

comment:6 Changed 11 years ago by brucemiller (bruce miller)

I assume you mean that if you installed something like p5.12-foo and p5.14-foo, the later one would overwrite the earlier one. I can see that this could be a problem, even if it would only rarely be needed. But while your solution keeps the two executables from conflicting, it also makes them both unusable. (at least not by the average Mac user, no offence intended)

Perhaps you could arrange that p5.12-foo would install to the versioned sitebin directory, but a plain p5-foo would install to a more common $path location?

What is the recommended approach to installing an executable perl script under macports?

comment:7 in reply to:  6 ; Changed 11 years ago by d-lamb (Derek Lamb)

Replying to bruce.miller@…:

But while your solution keeps the two executables from conflicting, it also makes them both unusable. (at least not by the average Mac user, no offence intended)

Perhaps you could arrange that p5.12-foo would install to the versioned sitebin directory, but a plain p5-foo would install to a more common $path location?

What is the recommended approach to installing an executable perl script under macports?

That is correct, they are unusable because they are not in the user's path.

The problem is not only with installing an executable perl script under MacPorts. For example, I installed some modules from CPAN that provide executables (e.g., nytprofhtml from Devel::NYTProf and cover from Devel::Cover). Both ended up in libexec presumably because of the sitebin flag in the Perl config.

I'm not sure of a way around it, besides the symlink party that you see with more than one Perl in /opt/local/bin.

So maybe this isn't just a MacPorts issue, but if I were to install more than one Perl on my system, how would I keep the binaries straight? Maybe it's something to ask the perlmonks.

comment:8 in reply to:  7 Changed 11 years ago by d-lamb (Derek Lamb)

Should have read this before I posted my reply: Make links to per-version tools Unfortunately it appears the best answer is "a bunch of symlinks". Yuck.

comment:9 in reply to:  7 Changed 11 years ago by brucemiller (bruce miller)

Replying to derek@…:

So maybe this isn't just a MacPorts issue, but if I were to install more than one Perl on my system, how would I keep the binaries straight? Maybe it's something to ask the perlmonks.

It isn't a MacPorts issue, per-se, but an issue with the way perl has been configured in MacPorts. I'd expect any perl scripts (as opposed to modules) built using the "standard" Makefile.PL (basically all of CPAN) is going to fail the same way.

comment:10 Changed 11 years ago by larryv (Lawrence Velázquez)

If you still have questions or concerns about this, you might want to inquire on the macports-users mailing list. I can’t really help, since I don’t know much about Perl.

comment:11 Changed 11 years ago by brucemiller (bruce miller)

Well, forget the part about perl. Imagine you compiled a program using c, or wrote a script using bash, or Language Of Your Choice. Now, suddenly, when you run make install on your project, your program doesn't go to /usr/bin, or /opt/bin or whatever. No, it goes into /opt/mysterious/glib-1.27/sitebin, or /opt/somewhereelse/bash-9.99/libfoobin. Most users can't find it. And if they do, should they put this crazy path into their $PATH? And update it everytime something changes at macports? And this, when you didn't even request a specific version of c, bash, perl, or whatever!

I'm trying not to get snarky, and I sympathize with the desire to support multiple versions. And I really do appreciate the work you guys are doing.

But you really can't just change the installation path to something version dependent, but provide no mechanism, tool or even suggestions of how to work around this.

I've used the standard build mechanism for packages in Perl, and it was nice that it worked on the Mac (I don't use one, but I have colleagues who do). I don't have a lot of opportunity to experiment with random, macports-specific, hacks on the build to try to work around this.

So, again, please: How should I modify my Makefile.PL so that it works in MacPorts?

Thank you;

comment:12 in reply to:  11 Changed 11 years ago by larryv (Lawrence Velázquez)

Again, ask on the mailing list. I’m not trying to punt on your question; it’s just that you’ll almost certainly get a better answer there. A lot more people monitor macports-users than check up on the Trac tickets.

comment:13 Changed 10 years ago by ghosthound

Owner: changed from ricci@… to macports-tickets@…

No longer maintainer

comment:14 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Owner: changed from macports-tickets@… to macports-tickets@…

comment:15 Changed 10 years ago by mojca (Mojca Miklavec)

Cc: mojca@… added

Cc Me!

comment:16 Changed 8 years ago by mojca (Mojca Miklavec)

Port: perl5 added; perl5.14 removed
Summary: perl5.14 sitebin & vendorbin flags may be inapproriateperl5.x: sitebin & vendorbin flags may be inapproriate
Version: 2.1.2

See also #50000.

Note: See TracTickets for help on using tickets.