On Mon, Nov 8, 2010 at 7:31 AM, Stuart D. Gathman <stuart@xxxxxxxx> wrote: > If the original > poster would present his use-case, that might help determine the > general usefulness of such a feature I have a bunch of users on Centos OS. They are climate researchers who use ncview, nco, grads, some other slightly obscure tools. There is a tendency for certain datasets to need a certain version of the tool, so that ideally multiple versions of the tool would be installed on the same machine for use in different instances. Also, some of these tools tend to fall behind or jump ahead of the centos distro in terms of library dependencies. That is, I can't find a centos rpm of a particular tool, but I can find a fedora or redhat rpm, which would be close enough except it depends on some library that is older or newer than the one I have installed. What I usually try to do in such cases is to fall back to the configure/make/make install stuff, but do it as a non-root user in userspace. That way I don't screw up the shared libraries. But it is usually a confusing, slow and labor intensive task, maybe because I don't really know what I am doing, maybe because config scripts are a bit less robust than one might like. It might make more sense to switch to ubuntu (has slightly better support for most of the tools in question), or donate some usable centos rpms, or something like that. Or install some virtual machines with different versions. This also seems possibly related to problems I have with the netcdf libraries, which do appear in rpms, but need to be compiled differently depending on how your application will be compiled. I'm not sure that this approach would help there or not, but the idea is similar - different flavors of the same thing living in different places on the same machine, use environment variable to decide which gets used. Dave _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list
