On 01/20/2014 03:03 PM, Jim Perrin wrote:
At 10am CST / 16:00 UTC we'll be starting the packaging office hours discussion for SIGs and Variants. if you've got some questions you'd like us to address, please email them to us, or ask your questions via irc in #centos-devel on freenode.
Hi.
I see you avoided talking about priorities of the repositories, and I actually spent last 10 minutes smiling (not laughing, but smiling) and thinking how easy you could solve all of what you talked with carefully configured priorities.
Here is what you can do with priorities:
Let's say you have current repo-core (base, updates,...) priority=50, repo-epel priority=40, internal repo-centosplus and repo-extras with priority=30, repo-cloud priority=20 for common packages for all Variants/products/packages inside Cloud SiG, and repo-openstack, repo-cloudstack, repo-ovirt and repo-opennebula with priority=10.
(For repositories that do not have priorities set, default would become priority of the base/core repo, in this case 50. Additional plugin of function would offer to add "Priorities=" for any repo inside /yum.repos.d/ and we could urge all 3rd party repos to publish new release packages ...bla, bla, bla, some or all that I proposed)
So distribution of packages is following, higher repo=higher priority:
repo-openstack repo-cloudstack repo-ovirt repo-opennebula packageZ-6.7.1 kernel-2.6.32-431-cs packageZ-6.6.5
repo-cloud kernel-2.6.32-431-cloud packageY-3.0.1 packageZ-6.6.2
repo-centosplus repo-extras kernel-2.6.32-431-centosplus packageX-1.0.3
repo-epel packageZ-6.5.8
repo-core kernel-2.6.32-431 packageX-1.0.0 packageY-2.5.7
So regular CentOS would use only repo-core and packages: kernel-2.6.32-431 packageX-1.0.0 packageY-2.5.7
Those that add EPEL would also have additional packages so their list of visible packages would be: kernel-2.6.32-431 packageX-1.0.0 packageY-2.5.7 packageZ-6.5.8
Those that on repo-core and EPEL add repo-centosplus and repo-extras would have their list of visible packages (for update for example): kernel-2.6.32-431-centosplus packageX-1.0.3 packageY-2.5.7 packageZ-6.5.8
Anyone wanting to use Cloud option packages that do not have special demands but only use common packages without overlap would use: repo-core, repo-epel,repo-centosplus, repo-extras, repo-cloud, and would have their list of visible packages (for update for example): kernel-2.6.32-431-cloud packageX-1.0.3 packageY-3.0.1 packageZ-6.6.2
For people using OpenNebula (in this example), they would also have turned on repo-opennebula on top of repo-cloud, but since it is empty, their list of visible packages would be same as above: kernel-2.6.32-431-cloud packageX-1.0.3 packageY-3.0.1 packageZ-6.6.2
For people using OpenStack (in this example), they would also have turned on repo-openstack on top of repo-cloud, and their list of visible packages would be: kernel-2.6.32-431-cloud packageX-1.0.3 packageY-3.0.1 packageZ-6.7.1
For people using OpenStack (in this example), they would also have turned on repo-cloudstack on top of repo-cloud, and their list of visible packages would be: kernel-2.6.32-431-cs packageX-1.0.3 packageY-3.0.1 packageZ-6.6.2
For people using OpenStack (in this example), they would also have turned on repo-ovirt on top of repo-cloud, and their list of visible packages would be: kernel-2.6.32-431-cloud packageX-1.0.3 packageY-3.0.1 packageZ-6.6.5
All packages in lower priority repositories would be hidden (unless forced) and would not mess with higher priority repositories.
Even if some package from one of the higher repositories would show up in upstream or EPEL, and/or even if that package would have higher version, priorities would block an update by default since package with that name already exists in higher repository.
Allowing that new package from upstream to be visible would be automatic (for users), you just have to remove package with same name from higher repository, no need to mess with include/exclude hell on each installed system or to release new <name>-release package for each change, just remove it from higher repository.
And you can even do it partially. You could for example remove it from repo-cloud and/but move it to a higher repository where older version is needed. So if only OpenStack needs older version, new package would be moved from repo-cloud to repo-openstack.
If only one Cloud software could use newer package from upstream, lets say oVirt, but not others, package from repo-cloud would be kept, but version from upstream would be "repeated"/doubled in repo-ovirt.
That would provide security for people using clouds based on CentOS that sudden upstreams change would crash their systems.
Similar automatic process (for users) would be to add newer versions of some package. Let's say OpenNebula needs newer version. They first add it into their repo-opennebula and use it. The others from SiG test their software with that version, and then you held a meeting and see what to do. You either move that packages down to repo-cloud, or not. If you do, single repo can, if necessary, add older version so they keep compatibility while others move on.
And it is ALL transparent to ALL users, all they have to do is to refresh their yum and new arrangement is already there, ready for update.
I do not see how you can beat centralized management like that with any priority-flat-based system you are contemplating about where multiple repositories have same priorities and can override one another with only version bump.
It will be interesting following the development of this issue.