Rex Dieter wrote: > Dag Wieers wrote: > >> On Fri, 27 Jul 2007, JC Júnior wrote: >> >>> I received a message about EPEL repository, I would like to know if this >>> repo is long term support too. >> Let me add that an effort to make sure EPEL is compatible with RPMforge >> failed as EPEL wants to become the only repository for RHEL and there is >> no interest to consider current RPMforge users. > ... >> EPEL refused the repotag, so one cannot easily identify where a package >> comes from and mixing repositories becomes harder. Since compatibility is >> a 2 way interaction and EPEL shows no interest, it is certain that mixing >> EPEL with other repositories may break something. > > Interesting you say that. It's quite a stetch from "no repotags" to > conclude "EPEL has no interest" in compatibility. > > In fact, epel (and fedora) repo is, by design and policy, supposed to be > compatible and considerate of other repos, e.g. most notably, > http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration > (among other project policy documents). > > When I posted the aforementioned repository collaboration document to the > rpmforge list(s) for comment, it received none. As much as I don't want the CentOS list to become the place where EPEL cooperation is discussed, it is obvious what their policy is. There is talk about cooperation and collaboration, however whenever Axel or Dag made any kind of suggestions on the EPEL list, they were not given very much "real" consideration. Certainly not the consideration that the current EXPERTS on 3rd party repositories should get. I found this especially troubling since RPMForge (and it's predecessors) and ATRPMS saw the 3rd party repo need and filled that need before Fedora even existed. The replies these repo maintainer where ... that is not how Fedora does things. EPEL is Fedora's project to do with as they see fit, so this is not really a problem. It did leave a bitter taste in my mouth on a personal level though. There is also now this posting on the EPEL message list and wiki too: Message list: https://www.redhat.com/archives/epel-devel-list/2007-July/msg00239.html Wiki: http://fedoraproject.org/wiki/EPEL/FAQ#head-9ddfe705d75fe928468e3c64c1135de7cb187860 (the link does not seem to work directly ... look for "Section 2", "subsection 4", entitled "What about compatibility with other third party repositories?") There is absolutely nothing wrong with EPEL doing whatever they want, but their policy on collaboration is really that they are the one add-on repository that all should use. Their reckoning is that all people who want to use or contribute packages should do so within their framework and guidelines. I'm sorry, but that is _NOT_ how it has to be. Some other shortcomings have also already been addressed, but not resolved, on the EPEL list (and Red Hat is taking action to solve some of them {to give credit where credit is due}). Issues like, What happens when someone with the "Desktop Product" tries to install foo, but foo requires bar, and bar is only in "Server Product" and not in "Desktop Product". There are only really 3 answers to this issue (well, 4 if you count use the CentOS package) and they are: 1. EPEL can provide packages in a separate part of the repo to act as glue if there are package differences between the least populated EL project (ie, Red Hat Desktop) and the most populated project (ie, RHEL AS). This does not need to be everything to upgrade (Red Hat would not like that) ... just unmet dependences for packages in EPEL. EPEL recently worked with CentOS to do just that with all the requirements to get yum and it's requirements into the EPEL repos for EL4. It is not quite as easy though if RHEL is involved (they can't upgrade desktop products to server products). 2. EPEL can say to users of the least populated project ... sorry, this doesn't work for you. They might also just not put things in the repo at all if there are unmet dependencies between versions. 3. EPEL could just create a separate repo where all deps are met for the desktop products. This would be a subset of packages from the EPEL server repo. (The CentOS policy of putting all the desktop and server packages in one repo is looking fairly good now, isn't it). 4. The people who need dependencies solved can just use a CentOS package if they can't get a dependency for something in EPEL. Again, I am not telling anyone to not use EPEL. I personally know and like many of the people who are maintaining packages in EPEL and it will be a great asset to the EL community. Dag Wieers, Dries Verachtert and Axel Thimm are also great assets to the EL community. What users can do is use the yum priorities plugin (yum-priorities in CentOS-5, yum-plugin-priorities in CentOS-4) and you can then get more than 1 repo to play together. For some complex installs, you may also need to use "exclude=" in your higher priority repos to get those filled by your lower priority repos. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20070730/2c883988/attachment-0004.sig>