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:
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
Doug Ledford <dledford(a)redhat.com>
GPG KeyID: CFBFF194
Infiniband specific RPMs available at