[CentOS-devel] Is it possible to merge elrepo.org contribute to centos main repository?

[Manuel Wolfshant]

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