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: perl-XYZ-1.2.3.i386.epel5.rpm 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-0004.sig>