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

[Ljubomir Ljubojevic]

On 01/16/2014 01:45 PM, Jim Perrin wrote:
> 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.
>

What I am striving for, in first round, to have "Priority" and "Enabled" 
lines into official .repo files. Once that is in place, everything else 
are next phases and will be much easier to deal with.

Those next phases will depend on how things progress, but they will 
basically come down to analyzing what repositories and packages are 
created within CentOS project and EPEL repositories.

Even if some of 3rd party repos decide not to play along (only thing 
they can do is to set undesirable priority value), they will be either 
marginalized or users would just be instructed/advised to change 
Priority value to what we think should be.

Notice that professionals already know how to deal with package 
conflicts. It's the newbies that are my focus in this quest.

One of the steps I am hoping for is (primarily GUI) package manager that 
will have profiles, both predetermined and installable via separate 
packages. That way we as a project, or someone outside of the project 
could create repository profile that will be used for generic or 
specific use case (CentOS-Core + EPEL + RPMFusion + repoX) already 
preconfigured, and user only needs to install package with profile we 
tell him to.

I already experimented with this, and my best idea is to have separate 
(~backup) directory for every profile installed (/etc/yum.repos.d/core, 
/etc/yum.repos.d/ovirt, /etc/yum.repos.d/desktop, etc.) and to have 
simple command for switching them to new profile, and to either:

1. copy .repo files from selected directory/profile to main directory 
(backuping and deleting everything prior to switch). My example package 
you can see here: 
http://rpms.plnet.rs/plnet-centos5-x86_64/RPMS.plnet-releases/plnet-dev-release-1.0-0.el5.noarch.rpm

2. create symlinks from selected directory/profile to main /etc/yum.repos.d/

3. use a method that will call "yum -c <profile-yum.conf>" or 
"--set-opt=" to just point to desired configuration.

4. More complicated way would be to add alias for "yum" so it points to 
latest installed profile config, and "yum-default" for using 
CentOS-Core/default profile/config.

Since each profile would be in separate package, updating yum config can 
be easily made, and maybe using virtual package to pull-in all of the 
main profiles one Variant can use, could make sure switching to other 
profiles can be done even without internet connection.


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

The problem is that that "base" is what RHEL caries. So protectbase 
plugin only protect CentOS-Core, and will not cover variant repositories?

If that is/becomes truth, then priorities/profiles will be necessary 
tool for accomplishing easy manipulation of various repositories and 
package configurations different Variants will need. And that is fine 
with me. CentOS-Core should stay as is, with only difference being 
provision of "hooks" other Variants can easily attach to so they can 
deliver packages they need that differ from CentOS-Core.

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

Thanks.


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

StarOS, Mikrotik and CentOS/RHEL/Linux consultant