On 9/1/2010 9:33 AM, R P Herrold wrote: > >> The mere fact that Stephen asked here is the proof that EPEL DOES care >> about other repos. I also would like to point to Kevin's message ( >> https://www.redhat.com/archives/epel-devel-list/2010-August/msg00158.html ) >> which also proves that EPEL does try to avoid creating interoperability >> problems [*] > >> Please, let's focus on technical issues and not restart an useless flame >> war. > > The elided [*] comment tosses some fuel toward the ignition > source, no? One swallow does not a Spring, make > > It is a fair question -- dist tags / repotags were kept out by > the efforts of some with @redhat emails. Has that changed? It's not so much a flame as an observation that package managers don't and can't work with uncoordinated changes in the same namespace. And repotags don't do much to help unless the package manager uses them - although they do help in diagnosing problems after they've happened. > There is a long tradition of differing level of > interoperability. Sadly, although one might wish that any > archive can interoperate with any archive, and that one never > 'steps' on another archive, that can can never come to pass, > for reasons noted in my post a couple years back to the EPEL > ML I'm not convinced. I've got plenty of disk space. If you are going to modify a stock library, name it something else and name the package it's in something else - and make the things that need your non-stock changes use your copy instead. Do the same things you'd do with it if you were developing and testing a modified version on your own machine while keeping the stock version in place and running. This also allows the scenario where different users on the same machine want to run packages from different repos. > The obvious means of maximizing portibility and NOT stepping > on another archive, is simply building packages that depend > ONLY on LSB provided interfaces, and uses a private namespace, > assigned by LANANA that approach exists, has existed, and > still work today. It is merely cumbersome -- so automate it!! I'm not convinced there either. Even if you follow LSB guidelines, uncoordinated packagers are going to step on each others' choices in compile options, config file layout. > I'll just point at LSB, and say: > It is there for a reason Does one or the other of the epel and rpmforge copies of viewvc violate lsb? If an update flips from one to the other your setup is broken - and it doesn't even involve dependencies. -- Les Mikesell lesmikesell at gmail.com