add another linking level for perl5 binaries?

Derek Lamb derek at boulder.swri.edu
Wed Mar 27 20:30:45 PDT 2013


On Mar 27, 2013, at 7:22 PM, Daniel J. Luke wrote:

> On Mar 27, 2013, at 4:18 PM, Derek Lamb <derek at boulder.swri.edu> wrote:
>> TL;DR:
>> 
>> Could we add a line to to perl5 portgroup file after line 174 that says
>> ln -s "${destroot}${prefix}/bin/${bin}" "${destroot}${prefix}/bin/${bin}${perl5.link_binaries_suffix}"
>> ?
> 
> but then what happens if you install p5.12-foo and p5.14-foo and p5.16-foo?
> 
> --
> Daniel J. Luke                                                                   

Same thing that happens when you install perl5.12 and perl5.14 and perl5.16?  The symlink from /opt/local/bin/perl points to whichever version is active (and similarly for perl5, perlbug, perldoc, perlivp, and perlthanks), so presumably if 5.12, 14, and 16 were installed and 16 was active, then all the symlinks for the module binary p5-foo would point to p5.16-foo (or pfoo-5.16, I guess).

There might be an edge case where say p5.16-foo was not installed, but p5.12-foo and p5.14-foo was installed and perl5.16 was active.  Then I'm not sure.  Deleting the unversioned symlink sounds reasonable in that case, since you don't have a module with that binary in the active perl version.  I could see how deactivating and going backwards might be tricky, though--you would have to go through all the "installed p5-*" to find those that have binaries that need to have their links changed.

I don't know exactly what happens during a deactivate/activate operation, but it seems like perl at least is already set up for something like this.  I'm new at this aspect of it, so maybe there's a good reason not to that I'm unaware of.

Derek


More information about the macports-users mailing list