[CentOS] Re: Mixing RPMforge and EPEL (Was: EPEL repo)

Johnny Hughes johnny at centos.org
Mon Jul 30 09:50:43 UTC 2007


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/signature.bin


More information about the CentOS mailing list