[CentOS-devel] Packaging Office hours at 16:00 UTC today

Tue Jan 21 21:04:08 UTC 2014
Ljubomir Ljubojevic <centos at plnet.rs>

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.

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

StarOS, Mikrotik and CentOS/RHEL/Linux consultant