From: Lars Hjemli Date: Thu, 11 Dec 2008 23:37:07 GMT Subject: Re: [RFC] cgit in git? Message-ID: <8c5c35580812111537v1144c9fdy19f2a3cc56e2a04f@mail.gmail.com> In-Reply-To: <7vwse6bart.fsf@gitster.siamese.dyndns.org> On Thu, Dec 11, 2008 at 23:35, Junio C Hamano wrote: > "Lars Hjemli" writes: > >> 2) the cgit release tarballs includes the needed git sources >> >> Option 2 is doable but still requires the fedora project to support >> two git packages (but now the 'git-for-cgit' package is hidden inside >> the cgit source tree). The good thing about this option is that it >> only requires some minor modifications to the cgit releases. > > I do not understand why this is any extra work for fedora. I imagined that it could have a ripple-effect on package dependencies, i.e. the git release used by cgit could have subtle 'incompatibilities' with the real git package, but I really don't know the first thing about packaging so this is just a guess. > Instead of > running "make get-git" and then running your build procedure, they need to > just run your build procedure because you now ship your source with the > matching version of the git source, which sounds like the right thing to > me. You do not install anything from the contained git.git area (we do > not do shared objects, nor public header files) to the end product, right? Right. > Doesn't cgit bind git.git as a subproject at the source level? I would > expect that the most natural release tarball for such a project would be a > single tarball that has both the superproject itself _and_ the submodules > it contains already extracted, iow, the state of your tree after you run > "make get-git". Your expectation makes sense to me, thanks for elaborating. Seth: would such a self-contained tarball solve the problems on your end? -- larsh