| My knee-jerk inclination to this post is to yell, "oh holy hell, yes!" That said, and as others in this thread have noted, there are actually two use cases that need to be satisfied. 1. Here, you've got a base system, and you want to install some piece of software in order to use it. You want this to be guaranteed, for some reasonable definition of "guaranteed," to work with your existing base system. 2. Here, you want to install packages within a segregated environment, and you want those packages to work with any packages previously installed in said environment. You're probably attempting to do something like recreating your deployment environment locally. It strikes me that there are only two issues preventing the latter from being subsumed by the former. 1. Not all package management systems provide a means to have multiple versions of a package/runtime/what-have-you installed at the same time. Often, this capability is there , but packages need to be specially crafted (unique names, etc.) for it to work. See Debian's various Ruby and Python runtime packages for example. 2. Not all package managers provide a way to install a set of specific package versions in a contained environment which is segregated and requires intention to enter. (Note that I'm ignoring the "there are different package formats" issue; I don't think is in practice a huge barrier, and the package maintainers should be involved anyway.) If we could get RPM and YUM to provide those services, then we could remove the vast majority of this duplication. Alternatively, if we all agreed that developers should just use Linux containers as development environments, then all we'd need is upstream to use native OS packages (which is, really folks, not very hard). Can we do that pretty please?? |