#36980: perl5.14 sitebin & vendorbin flags may be inapproriate -----------------------+--------------------- Reporter: derek@… | Owner: ricci@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: perl5.14 | -----------------------+--------------------- Comment (by jmr@…): 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. -- Ticket URL: <https://trac.macports.org/ticket/36980#comment:2> MacPorts <http://www.macports.org/> Ports system for Mac OS

#36980: perl5.14 sitebin & vendorbin flags may be inapproriate -----------------------+--------------------- Reporter: derek@… | Owner: ricci@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: perl5.14 | -----------------------+--------------------- Comment (by larryv@…): Replying to [comment:3 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. -- Ticket URL: <https://trac.macports.org/ticket/36980#comment:5> MacPorts <http://www.macports.org/> Ports system for Mac OS

#36980: perl5.14 sitebin & vendorbin flags may be inapproriate -----------------------+--------------------- Reporter: derek@… | Owner: ricci@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: perl5.14 | -----------------------+--------------------- Comment (by derek@…): Replying to [comment:6 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. -- Ticket URL: <https://trac.macports.org/ticket/36980#comment:7> MacPorts <http://www.macports.org/> Ports system for Mac OS

#36980: perl5.14 sitebin & vendorbin flags may be inapproriate -----------------------+--------------------- Reporter: derek@… | Owner: ricci@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: perl5.14 | -----------------------+--------------------- Comment (by bruce.miller@…): Replying to [comment:7 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. -- Ticket URL: <https://trac.macports.org/ticket/36980#comment:9> MacPorts <http://www.macports.org/> Ports system for Mac OS

#36980: perl5.14 sitebin & vendorbin flags may be inapproriate -----------------------+--------------------- Reporter: derek@… | Owner: ricci@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: perl5.14 | -----------------------+--------------------- Comment (by 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; -- Ticket URL: <https://trac.macports.org/ticket/36980#comment:11> MacPorts <http://www.macports.org/> Ports system for Mac OS

#36980: perl5.14 sitebin & vendorbin flags may be inapproriate -----------------------+-------------------------------- Reporter: derek@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: perl5.14 | -----------------------+-------------------------------- Changes (by ricci@…): * owner: ricci@… => macports-tickets@… Comment: No longer maintainer -- Ticket URL: <https://trac.macports.org/ticket/36980#comment:13> MacPorts <http://www.macports.org/> Ports system for OS X