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