On Mon, Jan 23, 2012 at 10:50 AM, Yury V. Zaytsev <yury at shurup.com> wrote: > On Mon, 2012-01-23 at 10:38 -0600, Les Mikesell wrote: > >> EPEL's policy is to not replace any upstream packages so there is >> generally no versioning issue if they are the only additional repo > > There is much more than just that to it, read inconsistent package > naming, "public" libraries residing together with the application in the > same package and the list goes on. > > On top of this there are things like packages compiled against libraries > with different ABI versions etc., which very quickly gets messy once > your package base becomes sufficiently large and you are mixing sources. > > All of this can only be fully resolved by a substantial effort to keep > repositories compatible, which in turn requires the resources that > neither RF or EPEL have to spare. I think this misses the point that they can't be compatible for the common case where RF wants to have a newer version of something that in turn needs newer supporting libraries. No amount of resources can solve an inherent conflict when the distribution and packaging systems don't have a concept of having multiple versions installed concurrently. > There have been some efforts to keep the repositories "reasonably" > compatible from both sides, but that's pretty much as far as you can get > given current situation; it will never be perfect. The design is just not there to permit it. Look at something as simple and frequently desired as running two different java applications under different jvm versions. The OS itself has no problem with that, but you can't get the packaging tools to deal with it. -- Les Mikesell lesmikesell at gmail.com