[CentOS-devel] Looking for input from EPEL

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