Application installation
From Perl QA
Note: This page mostly contains Sjn's personal unstructured braindump. Feel free to improve!
So, Salve dropped by #toolchain a while ago and started ranting about the difficulty of installing oddstuff on different systems. As the confusion ensued he learned that IRC wasn't the best place for launching grand and pompous machinations. So he did it here instead. :)
Contents |
[edit] Application types and their files
At work we make all kinds of different applications, and quite a lot of them are written in Perl, but don't necessary fit neatly into the "CPAN distribution" frame. These lists are an attempt of clearing up this mess.
[edit] Application file roles
Typically, an application will contain quite a few files which don't fit neatly into the CPAN distribution format, including:
- The application's primary config file
- Other app-internal config files
- External application config files (e.g. a drop-in app.conf file placed in /etc/httpd/conf.d in order to set up a virtual host in Apache so that your web application is functional from the moment it's installed)
- Host-specific application config files
- Application web pages
- Cross-application shared web pages (e.g. an index.html for a set of Catalyst web apps)
- Dynamic web apps (either using CGI or some framework like Catalyst)
- Templates for the web-pages
- Templates for generating host-specific config files
- Templates for generating templates (e.g. Module::Starter templates that are used during the build phase to generate templates)
- Daemon startup scripts (for installation into /etc/rc.d/init.d or equivalent)
- ........ ?
| File role | Made use of... | Installation target | ||
|---|---|---|---|---|
| before install | after install | in-system | in-app | |
| Primary app config file | X | X | ||
| App-internal config files | X | X | ||
| External application config files | X | X | X | |
| Host-specific config files | X | X | (X) | X |
| App webpages | X | X | ||
| Shared app data | X | X | (X) | |
| Dynamic web apps | X | |||
| Templates for webpages | X | X | ||
| Host-specific config file templates | X | X | ||
| Template-templates | X | |||
| Daemon startup scripts | X | X | ||
[edit] Application type classification
We're working with a few different "application types" here. Let's try too classify them:
- Monolithic application (think PostgreSQL, specialized, non-extendable)
- Application platform (think Apache, which enables "hosting" of other apps using a loosly coupled API like CGI)
- Sub-application (think Catalyst, which can run using Apache as a platform)
- Plugin application (think Apache, which lets Subversion/mod_svn to be just "dropped in" and it works)
- Plugin sub-application (think Subversion as an Apache module)
- Application framework (think Catalyst, which allows separate mini-applications to run using the framework)
- Framework sub-application (think about a specific Catalyst application)
- Configuration application (think about an app which only is used for configuration and/or setup of a system or application (the Bundle:: concept fits nicely in here))
- ......... ?
| Application type | Can host applications | Installation target | ||
|---|---|---|---|---|
| yes | no | in-system | in-app | |
| Monolithic application | X | X | ||
| Application platform | X | X | ||
| Sub-application | X | X | ||
| Plugin application | X | X | X | |
| Plugin sub-application | X | X | ||
| Application framework | (X) | X | ||
| Framework sub-application | X | X | ||
| Configuration application | X | X | X | |
[edit] Installation targets
There are several targets one might want to install a certain software "into". We're not talking about architecture or operative systems, but rather "packages".
So basically we're talking about two axis for installation. The first axis is a two-step install (one before deployment, in order to create the deployment package which later is installed separately) as opposed to a one-step direct install. The second axis is wether the installation is located in the "standard" location on a system (regardless of which conventions are followed - it may be Perl's /usr/lib/perl5, the File System Hierarchy Standard 2.3 or the Debian file system policies), as opposed to installation to an separate location for the intention of sharing the files using a network file system of sorts.
- The local file system, used by the local host only (host-distributed, non-packaged, direct install)
- The local file system, but exported to other hosts using NFS or similar methods (host-centralised, non-packaged, direct install)
- Into a distribution package (e.g. RPM or DEB) for later installation on a compatible host (host-distributed, packaged, indirect install)
- Into a distribution package (e.g. RPM or DEB) for later installation possibly using the the packaging system relocation feature (host-centralized, packaged, indirect install)
[edit] The role of OS distributors
As if things aren't complicated enough, OS distributors and their wish to support backward compatibility adds quite a bit to the complexity of this. In addition to establishing conventions for installation locations and use, they're very much interested in keeping an index of what's installed in order to keep track of package dependencies ("I need this to work"), contents ("I have these files"), services ("I can supply others with this feature/network service/shared object API/etc.) and consistency (e.g. to avoid cross-package file, API or network resource conflicts).
This is obviously good, as any decent sysadmin would tell you.
--Sjn 16:36, 16 July 2007 (BST)
