On Tue, Jun 17, 2014 at 6:35 PM, Stephen John Smoogen <smooge at gmail.com> wrote: > > > From the EPEL side of the fence, the reason that OpenStack isn't in EPEL > anymore is due to three factors: > > 1) You really can't parallel y install it unless you do it via software > collections > 2) Updates to it aren't guaranteed to be without headache (command come, > commands go, etc) > 3) Lifetimes of the stack are shorter and aren't supportable after they get > replaced. > > That is pretty much the nature of any large framework from Ruby on Rails to > OpenStack in that they are in many ways an OS inside of an OS and need to be > treated that way. EPEL is meant to be tools for the outer OS and wasn't > designed to be for the Inner OS. This is neither a problem with the > frameworks or EPEL, they are just completely different mindsets and problem > cases. > > This is where one repo to rule them all breaks down :). Maybe a federated > repository system might but it would take a lot of co-ordination that EPEL > people haven;'t had time for in the past. But, but, but.... All of those things you mention are artifacts of only having one namespace for packages and their dependencies (and partly by a somewhat related expected PATH and LD_LIBRARY_PATH). And they all just get worse if you add in uncoordinated repositories using the same names for different things. How about a special-case EPEL extension repo to hold/coordinate packages that you can't expect to update cleanly or transparently (and thus should never be left enabled) with documentation of what will break with each version and what to do about it. Packages/frameworks that don't care about backwards compatibility are never ideal, but if the versions/updates are centralized at least the users will go through the same painful experiences and be able to help each other out when things break. -- Les Mikesell lesmikesell at gmail.com