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

From: Greg Troxel <gdt@ir.bbn.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: John Keeping <john@keeping.me.uk>, git@vger.kernel.org
Subject: Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
Date: Wed, 07 May 2014 07:44:34 -0400	[thread overview]
Message-ID: <rmiha51dd99.fsf@fnord.ir.bbn.com> (raw)
In-Reply-To: <xmqqoazb944d.fsf@gitster.dls.corp.google.com> (Junio C. Hamano's message of "Mon, 05 May 2014 16:50:58 -0700")

[-- Attachment #1: Type: text/plain, Size: 2006 bytes --]

Junio C Hamano <gitster@pobox.com> writes:

> You raised a good point on the issue of external dependencies may
> impact Git as a whole, even for those who are not interested in the
> particular remote helpers at all.  I'll have to think about it.

(As I'm sure you know, but starting from the beginning.)  There are
basically two ways that a program can be built.  One is by a user on a
particular system.  There, checking to see if various libraries are
installed and if so enabling some additional feature (that isn't that
hard/time-consuming to build) is entirely reasonable.

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.

(I realize some packaging systems have a style where the union of the
possible dependencies must be present to build, and then the resulting
binaries are allocated to split packages.  But that's not universal, and
it still requires large amounts of unnecessary dependencies to build a
package from source.)

Ideally, the core of git would have a small set of dependencies, and
optional language bindings or remote helpers could be built
independently (by running a different build, after git proper was built
and installed).  It seems more likely that the property of independent
builds of optional components will be preserved if the various git-foo
pieces are in seaprate trees.  But if they are in subdirs of the main
git tree, and build by "./configure && make && make install" in the
subdir, that's arguably equivalent.

[-- Attachment #2: Type: application/pgp-signature, Size: 180 bytes --]