Ship with required modules and install them locally.
By including the module distributions we can be sure we have working versions and installation can proceed much more quickly. Installing them into an application local directory means that we won't get unintended changes when the user installs a module at the system level. It also makes it easier to support uninstalls, and allows multiple versions of the application with different module requirements to run on the same machine.
Although this idea would work great when using a dedicated apache/mod_perl setup, if the users decides to run your app on a apache/mod_perl setup that is shared with other apps, then your module versions may interfere with what the other applications expect.
mod_perl will only allow one version of a module to be running at one time, and the first one that gets loaded wins. So if you have two apps that have different INC paths with different versions of the same module, the one that gets loaded will depend on which app is 'requested' first on the server (unless you are already preloading the modules in perl_startup.pl). This could lead to some difficult to trace problems that only occur on server restarts...
But I guess if the user is willing to spend the time to get the app working on a shared apache/mod_perl setup then you can probably expect them to install the modules you require in the main INC tree and not require the privately installed module tree. It's just a matter of giving some extra INSTALL docs.
In reply to Re: Installation System Design for a Large Apache/mod_perl Application
by cees
in thread Installation System Design for a Large Apache/mod_perl Application
by samtregar
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |