From: Greg Troxel <gdt@ir.bbn.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
Date: Wed, 07 May 2014 19:38:41 -0400 [thread overview]
Message-ID: <rmizjit6txa.fsf@fnord.ir.bbn.com> (raw)
In-Reply-To: <536a8f6cd81e9_76ff7a52ec60@nysa.notmuch> (Felipe Contreras's message of "Wed, 07 May 2014 14:54:20 -0500")
[-- Attachment #1: Type: text/plain, Size: 2165 bytes --]
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. 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.
[-- Attachment #2: Type: application/pgp-signature, Size: 180 bytes --]
next prev parent reply other threads:[~2014-05-07 23:38 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-29 22:38 What's cooking in git.git (Apr 2014, #09; Tue, 29) Junio C Hamano
2014-05-05 18:45 ` John Keeping
2014-05-05 19:08 ` Felipe Contreras
2014-05-05 19:55 ` John Keeping
2014-05-05 20:34 ` Felipe Contreras
2014-05-05 21:43 ` Felipe Contreras
2014-05-06 17:59 ` Junio C Hamano
2014-05-06 18:54 ` Felipe Contreras
2014-05-05 23:50 ` Junio C Hamano
2014-05-06 0:20 ` Felipe Contreras
2014-05-06 0:39 ` Felipe Contreras
2014-05-06 8:07 ` John Keeping
2014-05-06 8:32 ` Felipe Contreras
2014-05-06 19:34 ` Junio C Hamano
2014-05-06 19:39 ` Felipe Contreras
2014-05-07 11:44 ` Greg Troxel
2014-05-07 19:54 ` Felipe Contreras
2014-05-07 23:38 ` Greg Troxel [this message]
2014-05-08 0:18 ` Felipe Contreras
2014-05-08 7:29 ` Chris Packham
2014-05-08 7:56 ` Felipe Contreras
2014-05-09 0:40 ` David Lang
2014-05-09 0:58 ` Felipe Contreras
2014-05-09 0:58 ` Submodule improvements (Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)) Jonathan Nieder
2014-05-08 18:31 ` What's cooking in git.git (Apr 2014, #09; Tue, 29) Junio C Hamano
2014-05-07 0:01 ` Junio C Hamano
2014-05-07 0:17 ` Felipe Contreras
2014-05-07 8:05 ` John Keeping
2014-05-07 9:26 ` Felipe Contreras
2014-05-07 18:56 ` Junio C Hamano
2014-05-07 19:28 ` John Keeping
2014-05-07 19:50 ` Felipe Contreras
2014-05-07 20:26 ` Felipe Contreras
2014-05-07 20:44 ` John Keeping
2014-05-07 21:38 ` Felipe Contreras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=rmizjit6txa.fsf@fnord.ir.bbn.com \
--to=gdt@ir.bbn.com \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.