On Wed, 1 Sep 2010, Manuel Wolfshant 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? [I dont CARE they make the external file name fuglier, frankly -- if a packging entity will not sign their work with a brand that can be readily discerned by external inspection, I'm not much interested in them anyway] 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 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!! The other parts of Smooge's question have as much to do with Red Hat's plans for interaction with its community adjunct archive, its Linux product in chief and the non-distribution of binary restrictions EPEL operates under, and the commercial partners adjunct archive. While I don't mind being asked, I certainly don't feel it is my, nor indeed CentOS', mandate to tell Red Hat how to run their business I'll just point at LSB, and say: It is there for a reason -- Russ herrold