[MacPorts] #26320: ikiwiki gives 'Bus Error' with perl5.8

[MacPorts]

#26320: ikiwiki gives 'Bus Error' with perl5.8
--------------------------------+-------------------------------------------
  Reporter:  geychaner@…        |       Owner:  tommyd@…           
      Type:  defect             |      Status:  reopened           
  Priority:  Normal             |   Milestone:                     
 Component:  ports              |     Version:  1.9.1              
Resolution:                     |    Keywords:                     
      Port:  ikiwiki            |  
--------------------------------+-------------------------------------------

Comment(by tommyd@…):

 Replying to [comment:15 geychaner@…]:
 > Replying to [comment:14 tommyd@…]:
 > >  * Since the perl5 setup calls $prefix/bin/perl Makefile.PL, the
 IkiWiki plugins land in $prefix/lib/perl5/vendor_perl/5.8.9, not the
 expected / wanted lib/perl5/vendor_perl/5.10.1
 >
 > Would overriding perl5.bin in the portfile fix this problem? That perl
 version detect code I put in post-patch could easily be moved to pre-fetch
 and set perl5.bin. If not, then there needs to be a way to override the
 perl version called by the perl5 setup, and this should be a MacPorts
 enhancement request.

 I tried that locally but the first thing I noticed is that overwriting
 `perl5.bin` within a variant is not acknowledged anywhere (either before
 the perl5 setup call nor afterwards). I think I remember that variants are
 executed a little differently from the rest of the code of a portfile -
 anyways, what I ended up locally was overwriting configure.cmd which had
 the incorrect perl5 binary. Then of course the ikiwiki files would land in
 the correct perl version - if the installation itself would go through
 even! Again, the problem are missing packages there.

 > > I understand that my current version is not working as it should, but
 I see no easy way to make it work properly with the mess MPs has with its
 perl version. Since my time I can devote to MP is rather limited, I could
 imagine two things:
 > >  * If you're intested I can make you the maintainer of the port and
 you can work out the issues in your pace (I have not much use of ikiwiki
 nowadays anyways)
 >
 > I'd do it, but I've already spent more time with it than I should, and
 it's ticked me off so much that, since I am only using MacPorts for this
 one thing, I'm considering bailing and just installing it the hard way (or
 upgrading the machine to SnowLeopard to get a perl5.10 the easy way).
 Also, I'm in Chile on a 2MB/s connection, so every uninstall/reinstall
 test cycle takes me hours.  Now that I have something that works, I'm
 tempted not to muck with it too much.

 Right, while I have a slightly better connection, I am still used to
 trigger all my install tasks with the infamous `-n` option... also because
 I'm still on an early core 2 duo and not on one of these fancy i5 / i7
 machines.

 > >  * I revert the Portfile back to the version without variants and we /
 you try to work out the perl issues in the auto-setup, for example by
 patching it so it works with 5.8.x as well
 > >  * If the previous thing is too hard to do, we could still bug the
 perl5 port owners to finally remove / replace the ancient 5.8 version
 >
 > I think it should be thrown right back at the perl5 port owners.  It
 really, '''really''' shouldn't be this hard.  Really.

 Right, that is what I am thinking of as well. I had a similar nightmare
 for a python-based ports where the situation with all the different
 py24-*, py25-* and py26-* ports is even worse. It would all be much, much
 easier if people like me wouldn't fear upgrading so much and we could just
 use binary packages.

-- 
Ticket URL: <https://trac.macports.org/ticket/26320#comment:16>
MacPorts <http://www.macports.org/>
Ports system for Mac OS