How to deliver an application to end users which depends upon things they don't have
By joe
- 2 minutes read - 318 wordsThis is the question I have for dust. Almost ready for initial release. Fixed most everything, and the one thing we are “punting” on is actually less being punted and more being worked around until we can get a better solution in place. The spec’s for it will be on the site too soon.
Ok … so assume a pure Redhat or Centos system (will work with others as well) for the moment. From there, several Perl modules are missing from the default install. We can package the modules up as RPMs, and make these available as part of a dependency in a yum repository. This will work.
Another possibility is to exploit par files. Par files are the rough Perl equivalent to jar files in java. They take an program and all dependent perl modules, and wrap them up into a single binary executable. This will still have library dependencies, as it also binds in the Perl binary into the binary itself, and uncompresses when it runs.
I am favoring this latter approach at the moment. This frees us from having to make sure that all the dependencies are installed on the end user system. One thing we keep running into are huge installation dependency radii … having so many dependencies that it renders installations error prone. Really, the more dependencies that you need to install to get your code going, the more likely it is that the installation will fail, or a secondary or tertiary dependency that exists will cause a failure.
We will provide both methods. But likely start with the par version. Whats nice is that
dust.pl --init
sets itself up correctly (initializes databases, adds in an /etc/init.d/dust command and enables it, copies the binary or script to the /usr/sbin directory), so that installation is designed to be as painless as possible. I want to make sure dependencies are also as painless as possible.