#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