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