"Lars Hjemli" [off-list ref] 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. 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?
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".
On Thu, Dec 11, 2008 at 23:35, Junio C Hamano [off-list ref] wrote:
"Lars Hjemli" [off-list ref] writes:
quoted
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
Lars Hjemli wrote:
On Thu, Dec 11, 2008 at 23:35, Junio C Hamano [off-list ref]
wrote:
quoted
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?
(I'm not Seth, nor do I play him on TV -- though I have been offered
his role in a small town production of "How the Grinch Stole
Christmas"... ;)
The downside to this is that cgit would be duplicating the git
sources, and thus, so would any distribution packages. If there is a
bug in git, both the git and cgit packages would need to be updated to
fix it.
Basically, Fedora tries hard to use system libraries rather than
having applications include their own local copies. (I recall some
zlib vulnerabilities years back that required way too many packages to
be rebuilt, since they each included their own copy of zlib.)
Obviously, since git is not intended to be used as a library, this
doesn't exactly match that situation. But cgit is using git as a
library at the moment and if we could find a way to only have one copy
of the git sources to maintain, that'd be ideal from a distribution /
packaging perspective. I do understand that it might not be as ideal
from either git or cgit developer / maintainer perspective, so the
consideration you're giving the issue is very much appreciated.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I never vote for anyone; I always vote against.
-- W.C. Fields