[CentOS-devel] using GIT as VCS for packaging rpms

Fri Nov 7 14:20:28 UTC 2008
Lennert Buytenhek <buytenh at wantstofly.org>

On Fri, Nov 07, 2008 at 01:29:33PM +0000, Karanbir Singh wrote:

> >>>	http://fedora.gitbits.net/
> >>
> >>do you really not use packages with $name[0] > a ?
> >
> >They are there, they're just not on the front page.
> 
> ah cool. it did seem a bit strange. So you guys decided on doing the
> one git repo per package route... That is the route I dont want to
> take with the centos stuff. Mainly :
> 
> 1- how would one checkout a complete tree ( eg, i want a 5.2-ppc branch 
> checkout, and include all packages in that branch )
> 
> 2- adding a new package would mean adding knowledge about that package 
> at every step of the way from the packagers upto the build masters, arch 
> masters, testing stages, release and sign stage, mirror and push stages. 
> I suppose one might work around that a bit by having yet another git 
> repo that only has / tracks package status but that seems ugly.
> 
> one thing that the repo-per-package route fix's for git is the ACL 
> issue. with everything in one git-repo, its tricky getting people-> 
> access levels going. Its almost a case of resorting to people doing 
> commits via patch on email. Which then in turn creates a bottleneck in 
> that only some specific people can commit into the builder-visible-repo.
> 
> or am i just thinking too much svn'ish and not enough git'ish ?

In git, you can't as easily checkout or commit to a subdirectory of
a given repository as in CVS or svn, which was the reason for opting
to put each package in its own repository, so that package maintainers
wouldn't have to check out the source tree for the entire distro to
maintain their package.  And as you say, access control is another
thing -- you _can_ apply commit-time checks to make sure that noone
commits to dirs they don't have access to, but using unix permissions
for that is just slightly easier.

You _could_ pretty easily make a 'super-repo' that has each of the
packages in the distro as subdirectories of one big dir, you could in
fact do that pretty easily due to the way git works.  But if the goal
is to be able to add packages easily to run them through the entire
build and release stage automatically, there's a bunch of metadata I
can think of, both on the distro level (whether to build this package
for i386 or i686 (glibc), whether to build it for i386 or not when
you're building for x86_64) and the build level ("the kernel package
should only be built on the octal core box") that you might want to
encode somewhere that you don't have space for if you represent each
package by just a directory in some other directory.  So to me it
would seem that all the metadata needed to build the distro should be
something that you want to version control individually?

(Note that the (1) use case is rather rare, and if you're not
truncating history when checking out, you'll end up with a couple of
gigabytes worth of checkout.)