perl5.x: sitebin & vendorbin flags may be inapproriate

[d-lamb (Derek Lamb)]

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.

[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.

[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;

[brucemiller (bruce miller)]

Cc Me!

[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.

[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?

[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.

[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.

[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.

[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.

[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;

[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.

[ghosthound]

No longer maintainer

[mojca (Mojca Miklavec)]

Cc Me!

[mojca (Mojca Miklavec)]

See also #50000.