One of the suggestions I've seen is to ship a complete Perl distro as part of my app, but this seems wrong: if a number of Perl-based apps took this approach, the user could end up with several copies of Perl (and libraries, and ...), each bundled into a different app.
I've been struggling with this myself, although not specifically with libperl. It seems to me that a conscious decision was made to not include a packaging system in the style of rpm, dpkg, SD, etc. and just go with the NeXT bundles for everything. I actually was close to not going with a mac because of this (although obviously I did in the end). That's what I get for working for a few years in release engineering, I guess.
Anyway, the lack of a real packaging system is now causing me pain. As far as I can tell, to depend on a new perl module (XML::Simple in this case), you have to include it and all its dependencies inside your bundle, minus anything that ships with OSX, of course. And that is simply horrible. Nevermind the wasted HD space when someone installs multiple apps that include XML::Simple, XML::Parser, and expat in their bundles--HDs are cheap anyway. What angers me is that it's a waste of time. On the other platforms, I just add a line somewhere that tells the pkg system that my app depends on perl's XML::Simple, and that's it, problem solved.
The irony of it all is that someone _already_ spent the time packaging expat and XML::Parser for their app--I just read a post from the amphetadesk author about it on the 'Restoring stock OS X perl 5.6' thread.
I did read everything I could find on bundles & friends. Most of it is like "here's how you turn your large monolithic application into a clickable bundle", not "here's how you develop a complex network of interdependent modules, each maintained separately, with bundles." If anyone has any suggestions on how to do the latter, I'm all ears.
-Dan
