On 01/22/2014 08:17 PM, Jim Perrin wrote: > > > 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. > I was so swamped that I failed to realize it was Jan 20th. >> >> 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. If CentOS has any desire to expand on the market share, it should stop being "only-for-admins" distro. > > >> 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 top few repositories "belong" to in this case Cloud SiG, then "you" = Cloud SiG Board or whatever. I thought that people from CentOS Project would coordinate/oversee SiG's. It does not really matter who controls the repositories for priority based repositories to work, providing that there is communication between people maintaining them. But even if there is no real coordination, those on top creating Variants still can control state of their products/software. > > >> 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. I said nothing about enforcing. I was just explaining even such cases are easy to solve. > >> >> 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. > But I am not allowed to do what matters, not if your official policy is different. My opinion is that if I were to start Desktop Variant (my interest), I would have to replace centos-release with centos-desktop-release with yum-plugin-priorities mandatory and all repositories with modified priorities. I would also have to add several <repository>-release packages or to just add <repository>.repo and GPG key files as default. That would include 3rd party repositories like RPMFussion with not-so-legal packages. No actual packages, just .repo files provided. So far, I understood that neither are allowed. First will be considered non-CentOS, and you will not sign-on on second, and crucial packages will not be supported by CentOS, since CentOS does not want or can not be associated with 3rd party repositories, and those will not be allowed on git.centos.org. So what we come down, if what I wrote is essentially true, or remains true to is non-CentOS name and separate infrastructure are required. Since only few .repo files are needed, infra is not a problem, just few maintainers coming together and producing a brand not associated with CentOS. Most of the packages could be moved to newly formed repositories, but with various people hitting various restrictions, I am betting that most of 3rd party repositories will stay outside of git.centos.org. If they can not shut them down, they will want to keep the number of packages they care about. And that will mean 3rd party repository issue will not go away. But that is not what I had in mind, I wanted that CentOS, just like other distributions are tolerant of at least some 3rd party repositories. Since: - official support of such repositories is not allowed (having their <reposotiry>.repo files provided out of the box), - you will not support solution via priorities that would make their adding easy for the user, - there are no people supporting my solution, then I do not see Desktop Variant, of any market share value anyway, will be possible. And without support from others I do not see any need to waste my energy to confront you repeatedly. So this will be the end of my push for mentioned changes. -- Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe StarOS, Mikrotik and CentOS/RHEL/Linux consultant