How to build a stand-alone package for a program with many dependencies?
I have a server running RHEL4 on which I would like to install some software with dependencies not met by the .rpms distributed by Red Hat. Much of the software I have running on that server is distributed in a stand-alone manner. For example, an application that requires Boost has Boost in one of it subdirectories instead of requiring me to install it separately or relying upon whatever version I might have installed. I would like to do something similar for a couple of pieces of software that have me caught in dependency hell, or for which I need newer versions than Red Hat current provides.
Is there an example or a tutorial somewhere that can walk me through the process of building such a distribution? It seems like I should only need to set up a directory to contain my stand-alone package, install all of my custom libraries and scripts there, then write startup scripts to ensure, for example, that numpy finds my custom-built version of lapack instead of Red Hat's version. Is it really that simple, or is there something else I have to keep in mind? Thanks. |
If you don't have a RHEL subscription, meaning you don't need to consider tainting your installation with non-RHEL packages versus breaking RHEL support, then you could try and see if third party repos like Centos' EPEL, RPMForge and Karan Singh and such have the package versions you require. If they don't then I would suggest you (use a workstation to) build your own packages and test on a staging machine before deploying to production. This way you at least reap the benefits from using available package management. Building RPMs usually isn't that hard, just need to get acquainted with the basics and experiment a bit, and sometimes you can use other upstream providers source packages like Fedora to ease rolling your own. The rpm.org site and Fedora Wiki carry docs about building RPM packages, should be real easy to find for you.
|
Quote:
|
Virtualization could help prevent pollution of your production environment in more than one way: in development by enabling you to test stuff w/o repercussions and in production serving as an isolation layer. Without virtualization you can still, to some extent, set up shop but it's just more risky. Especially when different versions of core system components (like Python versions) are involved. Tried chrooting things? I've used custom initscripts, LD_LIBRARY_PATH, LD_PRELOAD and other environment variables and whatnot to do things like that but I never saw one generic "HOWTO" for it. Taking into account the installation and maintenance overhead I'd rather avoid situations like that. If you still feel that you need to go down that road, I suggest you post a Real Life example and maybe some "best practices" will materialize...
|
You can try to use statifier (http://statifier.sf.net)
or Ermine (http://magicErmine.com) Both of them able to pack dynamically linked executable and all shared libraries ut's needed into one self-contained executable. Ermine behaves better on systems with memory randomization, but it's commercial |
Quote:
|
Quote:
Quote:
Quote:
One caveat though, since you run RHEL, is how virtualization affects licensing. You could easily install RHEL-compatible Centos-4 as VM guest though. |
All times are GMT -5. The time now is 03:09 PM. |