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

Jim Perrin

jperrin at centos.org
Wed Feb 26 17:48:16 UTC 2014



On 02/26/2014 10:47 AM, Les Mikesell wrote:
> On Wed, Feb 26, 2014 at 10:20 AM, Jim Perrin <jperrin at centos.org> wrote:
>>
>>> Is it better to have users COMPILE FROM SOURCE???? Because they f***ing DO!
>>
>> Not one single person has ever said that in this discussion. That's not
>> even what this is about. This is about including packages in the CORE
>> (yes, extras is enabled by default) distribution.
> 
> I say that.  And it is about the problem of easily creating yum
> conflicts with a mix of repositories.  I think that problem deserves
> some effort to fix.
> 
>> If a sig wants to create a 'centos-enhanced' distribution and pull these
>> repos in, that's entirely fine. I don't have a single problem with that
>> and would happily support it. That's entirely the point of the
>> SIG/variant framework. However we've always been protective of the core
>> distribution, and that's one of the reasons it's been successful.
> 
> The base portion isn't even part of the problem, though.
> 
>>> By the way, RepoForge is practically dead in the water so no need using
>>> it as EPEL vs Repoforge argument. If you were to create a poll on forums
>>> (2-3 weeks of announcement in advance would be enough to rally all for
>>> and against) where you would ask:
>>
>> Fine substitute any other repository name out there. There are dozens to
>> choose from.
> 
> Hence the problem.  Which set will provide the package a new user will
> almost certainly need and never break their update?  How much time
> would it take to explain this correctly to a new user?  How much
> damage will it do when yum stops updating?
> 
>> Still missing the point. It's not a popularity contest. Yes, those two
>> win hands down. It's about establishing a baseline or metric so that
>> OTHER repos might work toward gaining that same level of
>> acceptance/trust, AND making sure we don't allow conflicting repos by
>> default, thus breaking yum update.
> 
> Would it be possible to automate checking the entire contents of
> multiple repositories?  That is, without actually merging the repos,
> check that there are no missing/conflicting dependencies or contents
> (probably with EPEL as a requirement), no duplicate package names with
> differing contents, or anything else that might either break yum or
> cause surprises from replaced packages.   Maybe just having an
> objective validator and some repo manager cooperation would fix
> things.
> 
> 
>> Again, this is EXACTLY the point of the SIG/variant concept. I
>> challenged you before to do this exact thing for a desktop sig.
> 
> Would/could, the permissible contents be different for a SIG than for
> EPEL?   Could a SIG variant include, say, vlc or equivalent media
> players?
> 

It has to be something that we can legally distribute from a US law
perspective. If it fits that criteria, then yes.



>>> Maybe even "What is a proper way to do things" video that explains
>>> differences to other distro's for users that are coming from
>>> Ubuntu/Debian/Mint could help such transitions.
>>
>> Dunno about a video, but I am working on a wiki page that deals with the
>> various command translations ( apt-get install foo -> yum install foo).
> 
> And what are you going to suggest as a replacement for the
> repositories Ubuntu would let you enable?

The same repositories we already list via the wiki.

>>> Also worth thinking about is rebuilding EPEL and ElRepo packages inside
>>> CentOS build system, so control is absolute that it will not mess up
>>> anything.
>>
>>
>> We have been thinking about this, at least with EPEL. There are pitfalls
>> with doing this as well. Control is not absolute, as we do not own EPEL.
>> If we duplicate it, and adjust a package then we're a fork and we're
>> back to the same old interoperability discussion again depending on
>> what's changed, versions, and/or build deps.
> 
> It is the inclusion policy that is the problem with EPEL - the
> technical side is fine.  And I see less chance than ever of changing
> that.
> 

We don't have the same restrictions that EPEL does, so the barrier to
entry should be lower.



-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77



More information about the CentOS-devel mailing list