Re: [PATCH 1/2] Add expat and expat-devel dependencies (for http-push) to RPM spec.

[Junio C Hamano <junkio@cox.net>]

> Linus Torvalds wrote:
>> Quite frankly, I'd really prefer to see the git-core-http as a
>> separate package.
>>
>> I think it's ludicrous that people want to split out gitk (because
>> it wants tcl/tk), but that we then add all of these really obscure
>> dependencies for the http part.

One thing we could do is to push http-push out of the common
package and keep http-fetch.  I personally feel that the http
commit walker is as much core as gitk is.  If you are git://
capable that is great, and if you are git+ssh:// capable that
may be even nicer because you could push.  But let's face it:
there are always more pullers than pushers, and everybody can
talk http over his firewall.

Andreas Ericsson <ae@op5.se> writes:

> git-email; This one only uses Email::Valid->address(), so I'll import 
> that function from the perl module so this dependency can be dropped and 
> git-send-email can be in the 'git' package.

Hmph.  This should have occurred to somebody when we did the same
with subprocess.py, but obviously it went unnoticed.

> Programs introducing obscene or plain weird dependencies (cvsimport, 
> svnimport) can be put into their own package, but we should really try 
> to keep those extra packages to a minimum and simply force users who 
> want all the fluffy niceties of the 'git' package to install whatever's 
> required (or install with --nodeps, or from source, or...).

I am not so sure about that.  Why should the number of packages
matter?  We could argue that the current splitting of RPM
packages is half-done in that sense --- we lack the "tying
together" package which itself is empty but depends on
subpackages that implements common client-side.  Call that
git-scm (or "git") and have the end users install it, then it
would pull what it depends on along with it.  No?