On 01/21/2014 03:04 PM, Ljubomir Ljubojevic wrote: . > > 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. > It wasn't intentional. It's not something I normally consider (as I've stated a few times). You should have joined and discussed it with us. > > 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. This is a reasonably limited example. As you've proposed it, it will work. What you've proposed is only a subset of actual use cases though.It's already been demonstrably shown by others on this list that there are situations where this fails. You're trying to address this issue from a user perspective. I'm trying to solve it from a packaging/distribution one. These are not the same. > 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. I never had any intention of messing with includes/excludes. That's up to users and admins. > 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. You're thinking about this in the wrong scope. The distribution shouldn't be in the business of moving SIG packages around. The SIGs need to do this, collaborating among themselves if possible. If we as a distribution need to step in to do this, it should either be in a mentoring context, or as a mediator. > 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. > We cannot dictate this. We can recommend that they all use a common package, enforcing this would arbitrarily prevent some SIGs from progressing. > > 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. > This works without priorities as well. > It will be interesting following the development of this issue. > Why follow? The benefit with the structure we're working to implement is that you're free to change most every aspect of it. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77