On 02/26/2014 01:53 PM, Johnny Hughes wrote:
On 02/26/2014 05:31 AM, Karanbir Singh wrote:
On 02/26/2014 11:25 AM, Manuel Wolfshant wrote:
there are more than 100 repos out there, which ones are we going to add
Those who provide the most desired packages and have been qualified by the community as being in good shape.
this is the important thing - what I've been trying to stress for a while as well. This 'qualified by the community' needs to be a measurable metric.
Lets just get specific here an explain why this can be sticky.
OK, so repoforge and EPEL do not play nicely together. We would, in my opinion, only be able to include one or the other release file in our extras repo as installing both produces broken yum installs of packages.
That is but one example.
I personally would have no real problem with both an epel-release and an elrepo-release RPM in CentOS Extras ... but then why not also nux-desktop or remi or repoforge? Those will not all work together, who do we leave out?
I've already answered these questions in a previous message
Both EPEL and ELRepo have said they do not want to be a CentOS SIG and want to be "independent". We have offered and they have refused .. Okay fine, that is their choice, they are independent. If you want them in CentOS, tell them on their lists to join as a CentOS SIG.
So there exists a "if it's not a CentOS SIG , we do not include references to them even if people still need to use them " policy. Fine, why did you not say so from the beginning ? It would have shorten the thread significantly
Even IF we included these repos and they were disabled, the people who can not find how to do one yum install command in the wiki would also not be able to enable the .repo file without looking at the same wiki page or ask on IRC to get instructions. It is the same amount of time to edit a .repo file and enable it as to do yum install
Experience has shown that there is a huge difference between " ask google about a package, look for a repo, try to find out how to enable said repo , download some-release-file.rpm file yum install some-release-file.rpm " and "yum install some-release-file.rpm " Not to mention that very few people make use of yum-config-manager, despite its usefulness.
some-release-file.rpm. If we are going to put the release files in, then we need to have at least the most common options enabled.
I beg to differ. All we have to do is to include the package and teach people how to yum install it. It's far easier than asking them to look for a download link, download and install.
So, which do we add in and who gets left out
As I have said, I have already answered these questions
... personally to be fair, I think they should all be left out instead of picking favorites. I would also certainly not want to enable anything by default that replaced core packages.
Which is why the list was restricted to these 2 repos only and did not include IUS for instance - even if IUS is one of the most polite 3rd party repos