[CentOS-devel] Repository structures for SIG and variants in the future

[Jim Perrin]

On 01/15/2014 11:15 AM, Ljubomir Ljubojevic wrote:
> On 01/15/2014 02:47 PM, Jim Perrin wrote:
>> We'll never be able to make everyone happy or resolve all the issues. If
>> we're able to provide something that works well for the majority of end
>> users and makes project life easier for the builders/developers, I'll
>> consider that a win.
> 
> There is no need to over complicate this. Majority will be happy to have 
> "Enabled="  and "Priority=x" in CentOS-Base.repo (and other repo's), and 
> to define priority values for Tier1, Tier2, Tier3 with enough space 
> in-between for 3rd party repositories to nest them selves where they want.

This could also provide added complication. Let me explain via a
hypothetical situation:

We establish a priority structure for repos moving forward, but for the
idea to work, the expected structure must be inverted. If the cloud sig
provides a newer libvirt, which is covered by the base repository's
lower priority value, then you run into problems trying to install the
cloud sig's packages.




> Additional consensus between 3rd party repository maintainers to agree 
> on priority values and which repos should be Enabled by default would be 
> nice, but it is not necessary because the fact that newbies do not have 
> to mess with CentOS-Base.repo and 3rd party repos for default 
> instalation of CentOS + 3rd party will dramatically boost usability to 
> newbies who want stable Linux, even if CentOS Project does not provide 
> Installation media with EPEL and/or ElRepo kmods.
>

With 3rd party repositories in the mix, this becomes more of an issue.
Even if we establish standard ranges, and get ALL the 3rd parties to
agree to both our structure and the established ranges (unlikely), you
could potentially still end up with repoforge and epel (still
hypothetical, still example, no one freak out)  having a dependency
conflict during an update, because one had a package that didn't exist
in the other but dragged in a conflicting dep chain.

We cannot dictate what 3rd parties do, and we'll very likely have to go
through a period of proving to them that becoming a SIG and/or working
together is a good idea. There's quite a bit of tension about this from
many past experiences.



> So far, every newbie that installs CentOS on Laptop (and 
> Desktop/Workstation) and needs additional drivers has to go through hell 
> of manual downloading and instalation of release packages, then manual 
> installation of kmods for their wireless/ethernet to work. And so does 
> person who they contact for help. Not to mention if package they need is 
> in tier 2 or 3.

I agree, but this is where the variants can come into play. Once we have
the infra in place to do what we're discussing, there's absolutely
nothing stopping someone from making a 'CentOS for laptops' or whatever
that has these bits baked in. All it takes is git, and some interested
parties to lead and support the SIG.

> But with priorities already set, task is 90% done, no messing around 
> with .repo files, just fire and forget.

I disagree. I don't see priorities as a solution to the problem, but
more of a half-measure. The priorities and protectbase plugins are walls
to keep conflicting packages out. We're trying to keep conflicting
packages from existing. It's a different view of the problem.


> I know that I am pushing hard for this, but that is because I have been 
> waiting this opportunity for several years, and if priority reform is 
> not done, then it will be epic fail in my book for wider adoption of 
> CentOS in non-server environments.
> 
> 

Good! I want folks caring about CentOS and its guidance. The more folks
we have involved, the more things we're able to do.

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