[CentOS-devel] SIG repo layout and conflicts between projects within a SIG

Jim Perrin

jperrin at centos.org
Mon Jan 19 14:37:34 UTC 2015



On 01/19/2015 06:08 AM, George Dunlap wrote:
> At the moment, we're essentially using yum repos as the "patch"
> mechanism to CentOS Base: SIGs populate a repo with packages they want
> to add / override, and all other packages default to Base.
> 
> The current setup is that every sig has exactly one production repo
> per CentOS version.
> 
> Also, we seem to be wanting to see SIGs not as individual projects,
> but to make the 'G' an actual "group": so, for instance, the Virt SIG
> has both Xen and Docker, and we've recently approved oVirt.
> 
> But there's a bit of a conflict here: what if one project in the SIG
> wants to use the package from Base, and another project in the SIG
> wants to use a custom-built package?  Or what if both projects want to
> customize their packages in different ways?
> 
> In particular: the Docker project in the Virt SIG wants to supply
> updated versions of Docker; but at the moment uses the kernel package
> from Base.  The Xen project, on the other hand, needs to supply a
> different kernel package that has dom0 support enabled.
> 
> Up until this point, this hasn't been an issue because I've been doing
> Xen development in virt6-testing, and Lokesh has been doing Docker
> development in virt7-testing.  But I'm hoping to get Xen for CentOS 7
> out soon, and I was just about to upload the Xen kernel to the CBS,
> when it occurred to me that if I did so, then everyone using the
> virt7-testing repo for Docker would suddenly get my updated kernel as
> well.
> 
> So it seems we have a couple of ways to approach it.
> 
> 1. Keep it one repo per SIG, and make all projects in a SIG sort out
> shared dependencies.
> 
> 2. Allow one repo per *project* within a SIG (e.g., virt6-xen, virt7-docker)
> 
> 3. Have some alternate way of doing a "patch", instead of repos.
> 
> In the case of xen / docker, I haven't talked with Lokesh about this
> at all; it may be that he's fine with sharing a kernel with Xen.  But
> it does increase the workload: now Lokesh needs to maintain the Docker
> side of the kernel, whereas before they could just rely on our
> upstream to do a lot of that testing.  Furthermore, it increases the
> complexity of development and testing: before when doing kernel work,
> I could just test Xen; now the kernel needs to be tested by both Xen
> and Docker.  And finally, now users of both projects get a kernel
> update whenever either one does.
> 
> Which, of course, is pretty much the same as any other distro; but as
> a whole, at the moment at least, we have a lot less resources than any
> other distro our size and popularity.
> 
> On the whole I'm inclined to prefer #2.
> 

I believe option 2 was always the plan, with a few caveats.

1. We start with one repo to test procedures and make sure things are
working that way first.

2. We work to keep repo sprawl to a minimum, lest sigs start creating a
few dozen project repos when just a couple will do.



-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77



More information about the CentOS-devel mailing list