From: Junio C Hamano Date: Mon, 14 Nov 2005 08:10:54 GMT Subject: Re: [PATCH 1/2] Add expat and expat-devel dependencies (for http-push) to RPM spec. Message-ID: <7vr79j1wfl.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <437788A0.6030103@op5.se> > 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 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?