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.

Thanks for the reply. For better or for worse I do have a RHEL subscription to consider, hence my desire to build in a sandbox. If the vendor of my most important piece of software would finally fully support RHEL 5 all of my problems would be solved, but that won't happen until spring....

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

Thanks, you have given me a lot of food for thought. As you have probably guessed, I'm a bit inexperienced on the administrative side of Linux. My first step is clearly to establish a sandbox of some sort, either by VM or chroot. After that, I will have a look at the dependency tree for my project and likely return with some questions about the best way to proceed.

Thanks, in terms of fish vs fishing rod that's the best result one can hope for.


I didn't notice. And I don't think it matters. OK, unless you're trying to do the right stuff the wrong way...


A sound plan. I'm very much in favour of VM. It may require more resources to run than a chroot and require you to install an OS (or download a prefab image) but it is fast (save RAM state and be up and running again in seconds), efficient (save a snapshot and revert), safer than a chroot (you can inadvertedly install things elsewhere when prepping a chroot but not with a VM guest) and convenient in terms of networking (subnetting, bridge mode, DHCP) and sharing (either as DMZ host or image).

One caveat though, since you run RHEL, is how virtualization affects licensing. You could easily install RHEL-compatible Centos-4 as VM guest though.