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

Wed Feb 26 18:50:22 UTC 2014
Ljubomir Ljubojevic <centos at plnet.rs>

On 02/26/2014 06:48 PM, Jim Perrin wrote:
>
>
> 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.

If whole (current) community decides to vote, and they choose EPEL to 
standardize on, most repositories will accept it, because most of them 
anyway reference EPEL or require it for their repositories. At least for 
parts of repositories that will not replace anything in base/epel.

For those that need to change base/epel packages, you are NOT going to 
allow/support ANYWAY. So if they agree to play well with EPEL (if 
community chooses that EPEL release file is provided), then those rare 
occasions where something is wrong can be fairly easy to fix. There is 
MUCH better chance of repositories obeying the rules then if everything 
is "in the wild". Show them prize of recognition and acceptance if they 
obey rules, and many will follow them.


>>
>> 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.

Not at all. Only EPEL and Elrepo are so essential that I do not know a 
good admin that does not use them on at least one CentOS system, 
especially for Desktop/Workstation use, or on unsupported hardware like 
laptops.

>>
>> 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.
>

If good framework is established (3rd party repository wise), then that 
stuff can be in some other repository. But in order to do so, there has 
to be easy to manage repository hierarchy, without too much messing with 
yum config files.

Jim, you have challenged me, but to tie my hands behind my back and grab 
a rope, because without ability to install "illegal" 3rd party 
repository (vlc, gstreamer-bad, ...) without any hassle, there is no 
point in wasting any time on Desktop SIG.

<snip>



-- 
Ljubomir Ljubojevic
(Love is in the Air)
PL Computers
Serbia, Europe

StarOS, Mikrotik and CentOS/RHEL/Linux consultant