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
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:11
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
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
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:11
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.
quoted
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. ;)
quoted
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
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
From: Thomas Matysik <hidden> Date: 2016-06-15 22:42:11
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
From: David Kågedal <hidden> Date: 2016-06-15 22:42:11
Linus Torvalds [off-list ref] writes:
On Sun, 13 Nov 2005, Andreas Ericsson wrote:
quoted
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