Greg Troxel wrote:
> Felipe Contreras <felipe.contre...@gmail.com> writes:
> > Greg Troxel wrote:
> >> In a packaging system, dependencies are much more troublesome.
> >> Dependencies have to be declared, and the build limited to use only
> >> those declared dependencies, in order to get repeatable builds and
> >> binary packages that can be used on other systems. Dependencies that
> >> really are required are fine. But optional dependencies are a
> >> problem, because e.g. one doesn't want to require the presence of qt
> >> to build something (that isn't already enormous). So if git needs
> >> mercurial and subversion installed, plus perhaps 5 other things for
> >> less popular remote helpers, that starts to be a real burden.
> > It doesn't *need* them to build. The Mercurial/Bazaar dependencies are
> > optional, both at build-time and at run-time. Most distributions would
> > want to test the functionality they are distributing, and for testing
> > they do need these dependencies.
> My point is that a packaging of git needs to either decide to forego
> these optional parts, or to include them, in the default case.
That is currently the case. They would be included by default, but not
usable unless the *optional* dependencies are installed.
> So I'm merely trying to suggest that it's better to have a core
> package with a restrained set of dependencies, and then a way to build
> the other things independently (perhaps assuming the core is
> built/installed), each with their own dependencies.
I'm all in favor of 'make install' installing only the core of Git, and
different targets for all the other parts.
However, if you take a look at any distribution's packaing of Git you
would see why that wouldn't be desirable (they are full of hacks and
fixes). If the build system is eventually fixed so one package can do
'make install', another 'make install-p4', another 'make install-hg' and
so on, that would be great. But we are pretty far from that.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html