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

Johnny Hughes johnny at centos.org
Tue Jul 31 20:57:38 UTC 2007

Les Mikesell wrote:
> Dag Wieers wrote:
>> My believe is that repotags was not the issue. There was something
>> else that made it impossible. And I can not undo the thought that it
>> is because not having repotags makes EPEL authoritative and masks
>> dependency problems.
> Can you explain that?  Authoritative over who/what?

Authoritative over the other 3rd party repos.

People have already explained this a dozen times.  Lets pick a package.
 perl-XYZ-1.2.3.i386.rpm.  People see that, they don't see a repo tag
and they think, hey ... this is part of RHEL (or CentOS) ... then they
see perl-XYZ-1.2.3.rf.i386.rpm trying to replace it and they say .. hey,
rpmforge is replacing my core package.

Then CentOS or rpmforge field the troublecall to fix EPEL's broken
package deps.

Now, imagine the same senerio with:


fairly obvious where it came from ...

>> It has an unfair advantage for the repository that does not tag its
>> packages, and it is certainly not advantageous to the userbase.
> Advantage at what?  And if there is only one untagged repo, can't the
> userbase tell who to blame?
There is not 1 untagged repo ... there are many.

The WHOLE of the OS is untagged (or the majority of it).  For CentOS
that is 5 repos ... for RHEL it is at least 3 channels.

When people see UNTAGGED they think ... THE MAIN OS.  That is exactly
what EPEL wants.  They want to be part of the OS, with others repos
considered as 3rd Party repos.  They want to be THE AUTHORITATIVE REPO
for EL.  I don't know how it could be any clearer....

-------------- 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/20070731/4d72f489/attachment.sig>

More information about the CentOS mailing list