On Thu, Dec 11, 2008 at 23:35, Junio C Hamano <gitster@xxxxxxxxx> wrote: > "Lars Hjemli" <hjemli@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
