[Melbourne-pm] Meeting - Tomorrow night, Wednesday the 11th of April 2012

Toby Corkindale toby.corkindale at strategicdata.com.au
Tue Apr 10 00:36:00 PDT 2012


On 10/04/12 16:09, Malcolm Herbert wrote:
> On Tue, Apr 10, 2012 at 08:17:43AM +1000, Alfie John wrote:
> |Just a friendly reminder that Melbourne Perl Mongers is tomorrow night,
> |on Wednesday the 11th of April, 2012 and will start around 6:30pm:
>
> I'm yet to turn up to a meeting (hoping to make it this week) but would
> love a talk on how to make a portable app that can be deployed on
> multiple POSIX-like hosts without needing admin access.
>
> ie, no ability to install modules from the native package manager or
> online access to CPAN - looking to be able to deliver a single tarball
> containing everything required to run as a non-privileged user straight
> away when dropped into an arbitrary directory they have write access to
> (presumably an application home directory)
>
> I did ask about this (and received a response) but wasn't able to
> capitalise on it at the time ... a presentation on it would be good if
> anyone has something on the topic ...


I'm not sure I'm up to date on that state of affairs..

As far as I am aware, most people have moved to one of two solutions.
1) Package things up for the system's native packages, ie. .deb, rpm, etc.
This is annoying because you have to maintain several build systems 
though. (eg. debian/redhat/centos/ubuntu/solaris/freebsd/openbsd 
multiplied by i386/sparc/amd64/arm32/arm64 multiplied by say three 
different releases of each operating system is 105 different systems to 
build upon!)


2) Build a custom Perl in a local directory and then install all 
required modules into it as well. Then you can tar up the entire lot to 
ship it around to other systems, as long as they're fairly similar.
But it won't work between wildly different releases of operating 
systems, let along entirely different platforms.
(eg. Perl XS modules compiled on Ubuntu Server 11.10 64bit aren't going 
to work on freebsd on i386)



3)
There was a third option, PAR -- which takes perl, your module, and all 
the dependencies, and all their dependencies, and all the C shared 
libraries referenced, and zips them all up into a huge archive, with a 
small bit of code at the top to extract and run it.

The problem being that it's actually seriously hard to automatically 
determine all the CPAN modules in use, due to Perl's inconsistent ways 
of loading them randomly, all over the place.

For example:

   use Module::Load;
   use DateTime::TimeZone;
   my $tz = DateTime::TimeZone->new(name => 'local')->name;
   # $tz = 'Australia/Melbourne'
   $tz =~ s{/}{_}g;
   load "Module::For::$tz";

That will require you to have included Module/For/Australia_Melbourne.pm 
as well as *every other timezone* in case someone runs it in London or 
New York or whatever. But there isn't an easy way to tell that from an 
automated scanner, even if it loads the module and put hooks into the 
Perl loader.

Toby


More information about the Melbourne-pm mailing list