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

From: Greg Troxel <gdt@ir.bbn.com>
Date: May 7, 2014, 23:38 UTC
Message-ID: <rmizjit6txa.fsf@fnord.ir.bbn.com>
In-Reply-To: <536a8f6cd81e9_76ff7a52ec60@nysa.notmuch>

Felipe Contreras <felipe.contreras@gmail.com> writes:

Show 15 quoted lines

> 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. One choice means that anyone who builds the package from source has to have the dependencies, and the other means that users of the built package(s) can't use the features. I realize that in Linux it's perhaps typical to not worry about burdening builders because actually building is very rare, but that's only reasonable because of having only one OS and perhaps three CPUs; with dozens each, building from source becomes more frequent. 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.

It turns out in pkgsrc that git-svn is a meta-package (with no files) that depends on git-base (no man pages, no gitk) and p5-subversion. hg-git appears to be a separate source distribution, depending on a python implementation of the git formats. So perhaps the situation is currently ok. I was just trying to point out the issue to avoid regressions in the packaging situation.