From: Felipe Contreras <felipe.contreras@gmail.com>
To: Greg Troxel <gdt@ir.bbn.com>,
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:18:13 -0500 [thread overview]
Message-ID: <536acd4578ac_3caaa612ec76@nysa.notmuch> (raw)
In-Reply-To: <rmizjit6txa.fsf@fnord.ir.bbn.com>
Greg Troxel wrote:
>
> 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
next prev parent reply other threads:[~2014-05-08 0:30 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
2014-05-08 0:18 ` Felipe Contreras [this message]
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=536acd4578ac_3caaa612ec76@nysa.notmuch \
--to=felipe.contreras@gmail.com \
--cc=gdt@ir.bbn.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).