building from git using custom koji install

[Doug Ledford]

On Wed, 2008-07-23 at 23:51 -0400, Mike Bonnet wrote:
> On Wed, 2008-07-23 at 23:06 -0400, Doug Ledford wrote:
> > On Wed, 2008-07-23 at 22:27 -0400, Jesus Rodriguez wrote:
> > > On Wed, Jul 23, 2008 at 09:50:13PM -0400, Mike McLean wrote:
> > > > Jesus M. Rodriguez wrote:
> > > >> So am I correct in my assumption that koji expects the scm
> > > >> repository to house a single package?
> > > >
> > > > Yes. Furthermore, koji assumes that the simple command 'make srpm'  
> > > > issued from the checkout will create a single source rpm. There is not  
> > > > enough information passed to koji for it to handle anything otherwise.
> > > >
> > > > In your SCM layout with multiple packages, how do you generate the  
> > > > different srpms? Is there a real reason that they are all in one module?
> > > 
> > > We generate different srpms with the Makefile that exists in each
> > > subdirectory. For example, if you want an srpm for the web module
> > > cd spacewalk.git/web; make srpm
> > > 
> > > Want one for the java code, then cd spacewalk.git/java.
> > > 
> > > With SVN it seems completely doable because I could give the
> > > path to repo/spacewalk/java and have koji checkout just that
> > > directory. Seems to be a limitation of GIT in this case
> > > (or we're using it wrong) :)
> > 
> > Well, git was intentionally written to be basically a state machine of
> > the entire project.  So, housing more than one project in a single git
> > repo isn't wrong, but it does tie your various projects together at the
> > state machine level.  This is why you can't checkout just one
> > subdirectory from git, you have to grab the entire project.  I think I
> > heard mumblings of someone wanting to make subprojects work nicely in
> > git, but I haven't heard if it ever got off the ground.
> > 
> > Regardless though, koji won't work with what your current SCM layout
> > without modification to the koji code.
> 
> While that's true, I'm not sure we're definitely handling things
> correctly in the git case.  The git support in Koji hasn't gotten a lot
> of testing, and there are a lot of ways to setup a git repo.  However, I
> think that multiple projects in the same repo is probably something we
> want to support (since we support it in cvs and svn).

Just because these are things that are done in cvs and svn doesn't
necessarily mean we want to do them in git ;-)  Amongst other things, if
you put multiple projects into a single repo, then to build *any* of
those projects, you have to clone the *entire* repo.  In addition, you
already have to deal with the fact that you are cloning instead of
checking out like you do with cvs.  In other words, the overhead of
cloning a huge repo grows much more rapidly for git than for cvs, so the
pain of a multi-project repo is going to be felt much more acutely.

> The SCM URL you pass to Koji has a format of:
> 
> scheme://[user@]host/path/to/repo?path/to/module#revision_or_tag_identifier
> 
> With git we combine the /path/to/repo and the path/to/module into a
> single URL we pass to "git clone", essentially collapsing them both into
> a full module path (this is also what we do with svn).  Would it be more
> appropriate to treat the /path/to/repo as the location of the git repo
> which we would pass to "git clone", and /path/to/module as a
> subdirectory in the repo, which we would use as the base directory of
> the build, and look there for a .spec file?

I could certainly see that as being a valid interpretation of the url
string.

-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-buildsys-list/attachments/20080724/cec13f04/attachment.sig>