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

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

[Thomas Matysik]

Signed-off-by: Thomas Matysik <thomas@matysik.co.nz>
---

 git-core.spec.in |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

applies-to: 76d3d1c302c20b82fd976e958aabd19f7f01e7b5
b33499b703fbeac7e055a50a7f250ed71a516517
diff --git a/git-core.spec.in b/git-core.spec.in
index cf7e942..91f8677 100644
--- a/git-core.spec.in
+++ b/git-core.spec.in
@@ -7,9 +7,9 @@ License: 	GPL
 Group: 		Development/Tools
 URL: 		http://kernel.org/pub/software/scm/git/
 Source: 	http://kernel.org/pub/software/scm/git/%{name}-%{version}.tar.gz
-BuildRequires:	zlib-devel >= 1.2, openssl-devel, curl-devel  %{!?_without_docs:, xmlto, asciidoc > 6.0.3}
+BuildRequires:	zlib-devel >= 1.2, openssl-devel, curl-devel, expat-devel  %{!?_without_docs:, xmlto, asciidoc > 6.0.3}
 BuildRoot:	%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-Requires:	zlib >= 1.2, rsync, rcs, curl, less, openssh-clients, python >= 2.3, tk >= 8.4
+Requires:	zlib >= 1.2, rsync, rcs, curl, less, openssh-clients, python >= 2.3, tk >= 8.4, expat

 %description
 This is a stupid (but extremely fast) directory content manager.  It
---
0.99.9g

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

[Linus Torvalds]

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. 

There are probably more boxes with tcl/tk on them than there are boxes 
with curl and expat (on one box I use, I already have to compile with 
NO_CURL=1 to avoid getting the http programs.

		Linus

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

[Andreas Ericsson]

Linus Torvalds wrote:
> 
> Quite frankly, I'd really prefer to see the git-core-http as a separate 
> package.
> 

This would get rid of expat and curl dependencies. ssh, rsync and git 
protocols use external programs so they aren't exactly required (from 
the rpm point of view anyways, they'll just fail if rsync or ssh isn't 
installed). I.e. Good idea, but see below.

> 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. 
> 

Couldn't agree more. Moving out the {cvs,arch,svn}-import scripts made 
sense because they were only faintly related to git day-to-day 
operations and forced some really ridiculous dependencies down users 
throats (git requiring subversion was a funny one...).

It *might* make sense to build a very minimalistic package for 
server-side use only, but for client-side use it's really only confusing 
to have a dozen packages to install to get the full functionality.

While we're on the subject of confusing; How about not naming non-core 
packages git-core? It feels wrong to have git-core-http, git-core-cvs 
and git-core-svn since they, strictly speaking, aren't required for core 
operations.

So, to be nicely constructive then I suggest we create the following 
packages;

git-core; Low-level stuff with as few dependencies as possible (ssh and 
openssl should suffice, really). This should be everything needed for 
running a server and should be required by all other git-* packages. It 
will most likely be enough to run most client-side things as well.

git; holds all client side stuff useful for humans interfacing with git 
that introduces "normal" dependencies not necessarily found everywhere 
(gitk and suchlike).

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.


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...).

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

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

[Linus Torvalds]

On Sun, 13 Nov 2005, Andreas Ericsson wrote:
> 
> This would get rid of expat and curl dependencies. ssh, rsync and git
> protocols use external programs so they aren't exactly required (from the rpm
> point of view anyways, they'll just fail if rsync or ssh isn't installed).

Actually, the "git://" protocol (and local filesystem ones) doesn't need 
any external programs. So if you just want to follow another repository, 
you can do so even without ssh or rsync installed.

But yes, the nice thing about ssh(+git):// and rsync:// is that since we 
don't link against them or depend on them in general, you can certainly 
install git without having them, and don't need to make a dependency of 
it.

If there's some way to "suggest" ssh when installing git, that would be 
good, but I don't think rpm has that. And if somebody doesn't have ssh 
installed, they probably don't have a network, so maybe even that is 
unnecessary.

So depending on the curl _program_ would fall under the same harmless case 
as depending on ssh and rsync, but the thing is, we depend on it as a 
library, which is why we should split things up.

> Moving out the {cvs,arch,svn}-import scripts made sense because they 
> were only faintly related to git day-to-day operations and forced some 
> really ridiculous dependencies down users throats (git requiring 
> subversion was a funny one...).

Yes. 

NOTE! Git does actually require the "merge" program, which sometimes comes 
with the diff3 package, and more often comes with rcs.  As with ssh and 
rsync, it's an external program and only really required if you do 
development (you can fast-forward something that you're only tracking 
read-only without it), so in theory you don't absolutely need it, but we 
do have a dependency on RCS right now due to that.

Which is a bit strange, and sometimes wrong (the same machine that doesn't 
have curl installed also doesn't have rcs installed, but I compile git on 
it anyway, and it works fine, since I use that machine only as a backup 
thing to receive git packs - in case kernel.org goes down _and_ all my 
home machines magically turn into pumpkins, I'll still have another site 
I can get my git repos from).

> While we're on the subject of confusing; How about not naming non-core
> packages git-core? It feels wrong to have git-core-http, git-core-cvs and
> git-core-svn since they, strictly speaking, aren't required for core
> operations.

Yeah, that "git-core-xxx" thing is a bit strange, but on the other hand, 
it does make it clear that they all come from the same SRPM (the 
"git-core" SRPM) so in the end I think it's actually a good idea.

			Linus

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

[Andreas Ericsson]

Linus Torvalds wrote:
> 
> If there's some way to "suggest" ssh when installing git, that would be 
> good, but I don't think rpm has that.

It hasn't. It was designed to update software non-interactively.

> And if somebody doesn't have ssh 
> installed, they probably don't have a network, so maybe even that is 
> unnecessary.
> 

I *think* the ssh transport should work nicely over rsh as well. I don't 
have the slightest idea of where to find an rsh installation to test it 
with though.

> So depending on the curl _program_ would fall under the same harmless case 
> as depending on ssh and rsync, but the thing is, we depend on it as a 
> library, which is why we should split things up.
> 

True. But HTTP is a very simple protocol and git only uses a very small 
portion of curl's capabilities so it wouldn't be rocket-science to hack 
up some micro-replacement and always use the shipped stuff.

> 
>>Moving out the {cvs,arch,svn}-import scripts made sense because they 
>>were only faintly related to git day-to-day operations and forced some 
>>really ridiculous dependencies down users throats (git requiring 
>>subversion was a funny one...).
> 
> 
> Yes. 
> 
> NOTE! Git does actually require the "merge" program,

That depends on how it's used. If some script expects 'merge' to be 
there and does things that might break the index if it isn't, then it's 
required.

> which sometimes comes 
> with the diff3 package, and more often comes with rcs.  As with ssh and 
> rsync, it's an external program and only really required if you do 
> development (you can fast-forward something that you're only tracking 
> read-only without it), so in theory you don't absolutely need it, but we 
> do have a dependency on RCS right now due to that.
> 

It could require /usr/bin/merge instead. Seeing as people who install 
packages usually installs other things as packages too this would 
probably make more sense.

> Which is a bit strange, and sometimes wrong (the same machine that doesn't 
> have curl installed also doesn't have rcs installed, but I compile git on 
> it anyway, and it works fine, since I use that machine only as a backup 
> thing to receive git packs - in case kernel.org goes down _and_ all my 
> home machines magically turn into pumpkins, I'll still have another site 
> I can get my git repos from).
> 

Still though, be kind to the fairy godmother. ;)

> 
>>While we're on the subject of confusing; How about not naming non-core
>>packages git-core? It feels wrong to have git-core-http, git-core-cvs and
>>git-core-svn since they, strictly speaking, aren't required for core
>>operations.
> 
> 
> Yeah, that "git-core-xxx" thing is a bit strange, but on the other hand, 
> it does make it clear that they all come from the same SRPM (the 
> "git-core" SRPM) so in the end I think it's actually a good idea.
> 

The change would only mean that all packages will come from the "git" 
SRPM rather than the "git-core" SRPM so this point is moot unless there 
will ever be such a thing as the "git" SRPM to contend with (which will 
be less likely if we're it, so to speak).

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

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

[Linus Torvalds]

On Sun, 13 Nov 2005, Andreas Ericsson wrote:
> 
> I *think* the ssh transport should work nicely over rsh as well. I don't have
> the slightest idea of where to find an rsh installation to test it with
> though.

You're right, it should be possible to just do a

	export GIT_SSH=rsh

and things should just work.

But I don't have any machines that allow rsh either ;)

		Linus

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

[David Kågedal]

Linus Torvalds <torvalds@osdl.org> writes:

> On Sun, 13 Nov 2005, Andreas Ericsson wrote:
>> 
>> I *think* the ssh transport should work nicely over rsh as well. I don't have
>> the slightest idea of where to find an rsh installation to test it with
>> though.
>
> You're right, it should be possible to just do a
>
> 	export GIT_SSH=rsh
>
> and things should just work.
>
> But I don't have any machines that allow rsh either ;)

I do it all the time with a kerberos rsh.  It works fine.

-- 
David Kågedal

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

[Junio C Hamano]

> 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?

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

[Andreas Ericsson]

Junio C Hamano wrote:
> 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.
> 

Apparently it's not so easy. The Email::Valid thing contains a regex 
some 5000 chars long. I personally think it's a fair bit overkill for 
the purpose of send-email so we could well do with a much simpler 
verification.

> 
>>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?


Because it's a nuisance to keep track of them.


>  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?
> 

Isn't this exactly what I suggested (apart from git-scm)? client-side 
stuff goes in "git", basic functionality (server side stuff) in git-core 
and git-* for special functionality introducing odd dependencies (cvs, 
svn, http).

Since all packages would require git-core we can tack everything that 
doesn't require anything special in there and server-side installs will 
be smooth as you please.

This change should be done before 1.0 though, since people will probably 
expect some sort of package naming stability later.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

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

[Thomas Matysik]

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. 

Well, splitting out http occurred to me, but personally I don't have a
problem with installing expat (I'd need it eventually anyway) and I
figured anyone who did have a problem would say something.  ;-)

The reason for this patch is that the RPM currently fails to build
without expat-dev.

The reason for wanting to split out gitk is that, for a machine where I
will never run gitk, I think the following dependency list is ludicrous:

 fontconfig
 freetype
 tcl
 tk
 xorg-x11-Mesa-libGL
 xorg-x11-libs