Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 8, 2014, 00:18 UTC
Message-ID: <536acd4578ac_3caaa612ec76@nysa.notmuch>
In-Reply-To: <rmizjit6txa.fsf@fnord.ir.bbn.com>

Greg Troxel wrote:

Show 21 quoted lines

> 
> Felipe Contreras <felipe.contreras@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.

-- 
Felipe Contreras