git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)

git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)

[H. Peter Anvin]

The Subversion importer Perl script breaks RPM generation.  First of 
all, it introduces new module dependencies which don't exist in for 
example RHEL4.  The easiest way to deal with that is probably to fork 
off the subversion exporter into a separate package, but the really bad 
one is:

git-svnimport.perl:require v5.8.0; # for shell-safe open("-|",LIST)

... which RPM thinks means that you need a Perl module called v5.8.0 
which doesn't, of course, exist.  This is arguably an rpmbuild bug, but 
it nevertheless breaks at the moment.

I'm afraid I cannot update any of the kernel.org machines to 0.99.9 
until these problems have been cleaned up.

	-hpa

Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)

[Wolfgang Denk]

In message <43652934.8000308@zytor.com> you wrote:
> The Subversion importer Perl script breaks RPM generation.  First of 

Confirmed. Well, actually the RPM *build* works fine.

> ... which RPM thinks means that you need a Perl module called v5.8.0 
> which doesn't, of course, exist.  This is arguably an rpmbuild bug, but 
> it nevertheless breaks at the moment.

It's when trying to install the RPM that we get:

error: Failed dependencies:
        perl(v5.8.0) is needed by git-core-0.99.9-1.i386


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"There are things that are so serious that you can  only  joke  about
them"                                                    - Heisenberg

Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)

[H. Peter Anvin]

Wolfgang Denk wrote:
> In message <43652934.8000308@zytor.com> you wrote:
> 
>>The Subversion importer Perl script breaks RPM generation.  First of 
> 
> Confirmed. Well, actually the RPM *build* works fine.

No, it doesn't.  It runs to completion, but it produces the wrong output.

	-hpa

Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)

[Junio C Hamano]

"H. Peter Anvin" <hpa@zytor.com> writes:

> git-svnimport.perl:require v5.8.0; # for shell-safe open("-|",LIST)
>
> ... which RPM thinks means that you need a Perl module called v5.8.0 
> which doesn't, of course, exist.  This is arguably an rpmbuild bug, but 
> it nevertheless breaks at the moment.
>
> I'm afraid I cannot update any of the kernel.org machines to 0.99.9 
> until these problems have been cleaned up.

Fair enough.  We'd work it around just like we handle
send-email.

[PATCH] Do not try installing SVNimport on RPM

[Junio C Hamano]

HPA reports that svnimport uses perl 5.8.4 and the syntax it
uses to require confuses rpmbuild.  So let's try demoting the
problematic script just like we do with send-email.

Somebody should supply tested patches to split the package or
whatever is needed if they want to use these scripts on RPM
based systems.

Signed-off-by: Junio C Hamano <junkio@cox.net>

---

     "H. Peter Anvin" <hpa@zytor.com> writes:

    > git-svnimport.perl:require v5.8.0; # for shell-safe open("-|",LIST)
    >
    > ... which RPM thinks means that you need a Perl module called v5.8.0 
    > which doesn't, of course, exist.  This is arguably an rpmbuild bug, but 
    > it nevertheless breaks at the moment.
    >
    > I'm afraid I cannot update any of the kernel.org machines to 0.99.9 
    > until these problems have been cleaned up.

    Does this work for you?

 Makefile         |   10 ++++++++--
 debian/changelog |    6 ++++++
 debian/rules     |    3 ++-
 git.sh           |    1 +
 4 files changed, 17 insertions(+), 3 deletions(-)

applies-to: 5d3fb770835ba710480cbaf0c1b076a3a4affc54
e217a63c79ad93b26cb816eede1baf34e27b1e61
diff --git a/Makefile b/Makefile
index 1163dda..c60fb6b 100644
--- a/Makefile
+++ b/Makefile
@@ -52,7 +52,7 @@
 
 # DEFINES += -DUSE_STDEV
 
-GIT_VERSION = 0.99.9.GIT
+GIT_VERSION = 0.99.9a
 
 CFLAGS = -g -O2 -Wall
 ALL_CFLAGS = $(CFLAGS) $(PLATFORM_DEFINES) $(DEFINES)
@@ -94,7 +94,7 @@ SCRIPT_SH = \
 SCRIPT_PERL = \
 	git-archimport.perl git-cvsimport.perl git-relink.perl \
 	git-rename.perl git-shortlog.perl git-fmt-merge-msg.perl \
-	git-findtags.perl git-svnimport.perl git-mv.perl
+	git-findtags.perl git-mv.perl
 
 SCRIPT_PYTHON = \
 	git-merge-recursive.py
@@ -142,6 +142,12 @@ else
 	GIT_LIST_TWEAK += -e '/^send-email$$/d'
 endif
 
+ifdef WITH_SVNIMPORT
+	SCRIPT_PERL += git-svnimport.perl
+else
+	GIT_LIST_TWEAK += -e '/^svnimport$$/d'
+endif
+
 LIB_FILE=libgit.a
 
 LIB_H = \
diff --git a/debian/changelog b/debian/changelog
index 5fd31b7..5c5ba55 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+git-core (0.99.9a-0) unstable; urgency=low
+
+  * GIT 0.99.9a
+
+ -- Junio C Hamano <junkio@cox.net>  Sun, 30 Oct 2005 14:30:03 -0800
+
 git-core (0.99.9-0) unstable; urgency=low
 
   * GIT 0.99.9
diff --git a/debian/rules b/debian/rules
index 568d430..e6b6bad 100755
--- a/debian/rules
+++ b/debian/rules
@@ -26,8 +26,9 @@ else
 endif
 
 # We do have the requisite perl modules in the mainline, and
-# have no reason to shy away from this script.
+# have no reason to shy away from these scripts.
 export WITH_SEND_EMAIL=YesPlease
+export WITH_SVNIMPORT=YesPlease
 
 PREFIX := /usr
 MANDIR := /usr/share/man/
diff --git a/git.sh b/git.sh
index 94940ae..cd800bc 100755
--- a/git.sh
+++ b/git.sh
@@ -70,6 +70,7 @@ send-email
 shortlog
 show-branch
 status
+svnimport
 tag
 verify-tag
 whatchanged
---
0.99.9.GIT

Re: [PATCH] Do not try installing SVNimport on RPM

[Junio C Hamano]

This is based on Ryan's suggestion.  Running 'rpm --requires'
on the resulting RPM  seems to want these -- which I cannot
judge if this would be something that satisfies you.  I'd push
it out if it is OK with you.

Also I do not see "use v5.8.0" you mentioned in a separate
message anywhere in the tree, so I am hoping that should be OK.

junio@hera:~/git(0)$ R=~/rpms/RPMS/i386/git-core-0.99.9a-1.i386.rpm
junio@hera:~/git(0)$ rpm -q -i -p $R --requires | grep 'perl '
/usr/bin/perl
perl >= 0:5.006
perl >= 0:5.008
junio@hera:~/git(0)$ exit

 ------------
[PATCH] Work around an RPM build problem.

The require statement at the top of git-svnimport seems to confuse
rpmbuild dependency generation.  It uses the newer notation "v5.8.0",
and rpm ends up requiring "perl(v5.8.0)", while we would want it to
say something like "perl >= 0:5.008".

Ryan suggests old-style "require 5.008" might fix this problem, so
here it is.

Signed-off-by: Junio C Hamano <junkio@cox.net>

---

 git-svnimport.perl |    2 +-
 Makefile           |    2 +-
 debian/changelog   |    6 ++++++
 3 files changed, 8 insertions(+), 2 deletions(-)

applies-to: 5d3fb770835ba710480cbaf0c1b076a3a4affc54
c846e15ee31b7226a715646f633fc1fdd2e14cd9
diff --git a/git-svnimport.perl b/git-svnimport.perl
index 20a8572..45b6a19 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -10,7 +10,7 @@
 # The head revision is on branch "origin" by default.
 # You can change that with the '-o' option.
 
-require v5.8.0; # for shell-safe open("-|",LIST)
+require 5.008; # for shell-safe open("-|",LIST)
 use strict;
 use warnings;
 use Getopt::Std;
diff --git a/Makefile b/Makefile
index 1163dda..5bb5108 100644
--- a/Makefile
+++ b/Makefile
@@ -52,7 +52,7 @@
 
 # DEFINES += -DUSE_STDEV
 
-GIT_VERSION = 0.99.9.GIT
+GIT_VERSION = 0.99.9a
 
 CFLAGS = -g -O2 -Wall
 ALL_CFLAGS = $(CFLAGS) $(PLATFORM_DEFINES) $(DEFINES)
diff --git a/debian/changelog b/debian/changelog
index 5fd31b7..7d18483 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+git-core (0.99.9a-0) unstable; urgency=low
+
+  * GIT 0.99.9a
+
+ -- Junio C Hamano <junkio@cox.net>  Sun, 30 Oct 2005 15:03:32 -0800
+
 git-core (0.99.9-0) unstable; urgency=low
 
   * GIT 0.99.9
---
0.99.9.GIT

Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)

[Ryan Anderson]

[-- Attachment #1: Type: text/plain, Size: 673 bytes --]

H. Peter Anvin wrote:
> The Subversion importer Perl script breaks RPM generation.  First of
> all, it introduces new module dependencies which don't exist in for
> example RHEL4.  The easiest way to deal with that is probably to fork
> off the subversion exporter into a separate package, but the really bad
> one is:
> 
> git-svnimport.perl:require v5.8.0; # for shell-safe open("-|",LIST)
> 
> ... which RPM thinks means that you need a Perl module called v5.8.0
> which doesn't, of course, exist.  This is arguably an rpmbuild bug, but
> it nevertheless breaks at the moment.

If you change that to the traditional statement of "require 5.008;",
does it fix things up?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)

[Junio C Hamano]

Ryan Anderson <ryan@michonline.com> writes:

>> git-svnimport.perl:require v5.8.0; # for shell-safe open("-|",LIST)
>> 
>> ... which RPM thinks means that you need a Perl module called v5.8.0
>> which doesn't, of course, exist.  This is arguably an rpmbuild bug, but
>> it nevertheless breaks at the moment.
>
> If you change that to the traditional statement of "require 5.008;",
> does it fix things up?

Ah, I like that better.  Let me try that.

Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)

[Junio C Hamano]

"H. Peter Anvin" <hpa@zytor.com> writes:

> git-svnimport.perl:require v5.8.0; # for shell-safe open("-|",LIST)
>
> ... which RPM thinks means that you need a Perl module called v5.8.0 
> which doesn't, of course, exist.  This is arguably an rpmbuild bug, but 
> it nevertheless breaks at the moment.

I took Ryan's suggestion and pushed 0.99.9a out.  Does it make
RHEL4 happy?

Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)

[Chris Wright]

* Junio C Hamano (junkio@cox.net) wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
> 
> > git-svnimport.perl:require v5.8.0; # for shell-safe open("-|",LIST)
> >
> > ... which RPM thinks means that you need a Perl module called v5.8.0 
> > which doesn't, of course, exist.  This is arguably an rpmbuild bug, but 
> > it nevertheless breaks at the moment.
> 
> I took Ryan's suggestion and pushed 0.99.9a out.  Does it make
> RHEL4 happy?

It's fine for FC3.  Certain irony that git now effectively requires
subversion.  I'm all for splitting these out, but have no time until
later in the week.  BTW, mind pushing the tag?

thanks,
-chris

Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)

[Junio C Hamano]

Chris Wright <chrisw@osdl.org> writes:

> It's fine for FC3.  Certain irony that git now effectively requires
> subversion.

Haha.

> BTW, mind pushing the tag?

Done; thanks for noticing.

Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)

[H. Peter Anvin]

Chris Wright wrote:
> 
> It's fine for FC3.  Certain irony that git now effectively requires
> subversion.  I'm all for splitting these out, but have no time until
> later in the week.  BTW, mind pushing the tag?
> 

The git-core RPM definitiely needs to be split.  Doubly ironic that it's 
called "core".

	-hpa

Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)

[Linus Torvalds]

On Mon, 31 Oct 2005, H. Peter Anvin wrote:
> 
> The git-core RPM definitiely needs to be split.  Doubly ironic that it's
> called "core".

I don't think it's necessarily ironic. It's actually a good thing.

I think that what we want to have is one _project_ (called "git"), which 
can generate multiple RPM's ("git-core", "git-svnimport", "git-docs", 
whatever).

So I think it was good that we called the RPM "git-core". We've just not 
yet done the obvious thing to create a few _other_ RPM's.

Now, I'm not certain how happy RPM would be with having one source RPM 
generate multiple binary RPM's, so we might have problems with some stupid 
RPM rules, but I think we should really do this. There's always going to 
be some extra feature that not everybody needs, but that it would be silly 
to have its own project for. 

Having one bigger project means that it's much easier to maintain, and 
there's less administrative overhead (good maintainers are really hard to 
find: you should realize how lucky we are to have Junio). Trying to split 
up the source code into independent projects at this level would just be 
much more pain than it's worth. But clearly we want to split up the RPM's.

		Linus

Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)

[H. Peter Anvin]

Linus Torvalds wrote:
> 
> Now, I'm not certain how happy RPM would be with having one source RPM 
> generate multiple binary RPM's, so we might have problems with some stupid 
> RPM rules, but I think we should really do this. There's always going to 
> be some extra feature that not everybody needs, but that it would be silly 
> to have its own project for. 
> 

RPM is more than happy to do this.  It's a standard feature of RPM.  The 
current RPM, however, is structured in a way that makes it somewhat 
painful, as it depends a little too much on wildcards.

	-hpa

Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)

[Horst von Brand]

Linus Torvalds <torvalds@osdl.org> wrote:
> On Mon, 31 Oct 2005, H. Peter Anvin wrote:
> > The git-core RPM definitiely needs to be split.  Doubly ironic that it's
> > called "core".

> I don't think it's necessarily ironic. It's actually a good thing.
> 
> I think that what we want to have is one _project_ (called "git"), which 
> can generate multiple RPM's ("git-core", "git-svnimport", "git-docs", 
> whatever).

Better cut along outside requirements: git-svn, git-cvs, git-scm-du-jour,
git-gtk. Please _don't_ split out documentation.

> So I think it was good that we called the RPM "git-core". We've just not 
> yet done the obvious thing to create a few _other_ RPM's.

Right.

> Now, I'm not certain how happy RPM would be with having one source RPM 
> generate multiple binary RPM's,

Works fine. It is exactly what is used to build -devel packages. What
doesn't work is doing multiple architectures, e.g. creating
git-core-1.2.3.i386.rpm and git-gitk-1.2.3.noarch.rpm, in one go.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)

[Junio C Hamano]

"H. Peter Anvin" <hpa@zytor.com> writes:

> Chris Wright wrote:
>> It's fine for FC3.  Certain irony that git now effectively requires
>> subversion.  I'm all for splitting these out, but have no time until
>> later in the week.  BTW, mind pushing the tag?
>
> The git-core RPM definitiely needs to be split.  Doubly ironic that it's 
> called "core".

BTW, did that "require 5.008" change make the resulting package
RPM happy on RH-EL4?

I agree that it is an extremely good thing to split the binary
packages into separate ones so that the system administrators
can pick and choose only the bits that are needed.  Here is a
strawman:

git-tla-import, git-cvs-import, git-svn-import, ...::
	Importers, one per foreign SCMs.

git-docs::
	Generated documentation from Documentation hierarchy.

git-core::
        All the rest, plus man pages.  We could separate out
	commit walkers if we wanted to, but I do not think that
	is necessary.

Having said that, I consider this purely binary packaging issue.
I.e. I do not think you are advocating for splitting the source
tree.

I do not know much about how things are done in the RPM world,
but is there a concept of "the upstream" vs "packaging
maintainer" there?  IOW, are the majority of RPM binary packages
done by the upstream maintainer?

I am currently generating i386 RPMs and i386 debs myself but I
am not particularly proud of the current setup.  I do not have
an RPM based machine that I can install the result myself to
test (which is what started this thread).  Since I am not a
Debian developer (and I do not particularly wish to become one
myself), the debs I generate will not be official anyway.
Personally I'd be happier if I can just lose rpm and deb targets
from the "upstream" Makefile (git-core.spec file and debian/
subdirectory as well while we are at it), ask "packaging
maintainers" to pull from kernel.org/ tree and do RPMs and Debs
outside.

On the other hand, having the basic support for packagers in the
upstream might be easier for port maintainers.  I honestly do
not know.

One thing we could do without breaking much of the current
arrangement is to have a team of people to help porting for
major packaging formats (RPMs and Debs mostly but I know we have
OpenBSD and Darwin people here too), and ask them to feed me the
updates to rpm/deb/whatever target in the Makefile as needed.
Especially before a major release I could ask them to test
things out and generate binary packages, perhaps taken out of
the tip of the master branch, or even another "for-porters"
branch for this purpose.

Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)

[H. Peter Anvin]

Junio C Hamano wrote:
> 
> I do not know much about how things are done in the RPM world,
> but is there a concept of "the upstream" vs "packaging
> maintainer" there?  IOW, are the majority of RPM binary packages
> done by the upstream maintainer?
> 

It does both ways.  I think Chris Wright has been doing the formal 
maintenance of RPM for Fedora.

Latency is an issue, though, especially for kernel.org.

	-hpa

Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)

[Martin Langhoff]

On 11/1/05, Junio C Hamano <junkio@cox.net> wrote:
> git-tla-import, git-cvs-import, git-svn-import, ...::
>         Importers, one per foreign SCMs.

I concur generally with the plan, except that I think we should wrap
the import/export scripts together(*). One-script-per-package is
pretty awkward, and yet the dependencies for a
git-export-import-scripts packages are going to be awful as they'll
often pull a whole raft of SCMs.

Hmmm.

Perhaps git-tla-glue, git-cvs-glue, git-svn-glue, where glue stands
for importers, exporters, tools, etc?

*- I'm starting to think that the script to replay git commits into
cvs that I posted last week (cleaned up patch coming soon)  should
follow the git-cvsimport convertion and be something along the lines
of git-cvsexportpatch, to be followed by git-cvsexport which would
automate discovering what patches need exporting and drive
git-cvsexportpatch.

> git-docs::
>         Generated documentation from Documentation hierarchy.
>
> git-core::
>         All the rest, plus man pages.  We could separate out
>         commit walkers if we wanted to, but I do not think that
>         is necessary.

git-gitk ;-)

> I am currently generating i386 RPMs and i386 debs myself but I
> am not particularly proud of the current setup.  I do not have
> an RPM based machine that I can install the result myself to
> test (which is what started this thread).  Since I am not a
> Debian developer (and I do not particularly wish to become one
> myself), the debs I generate will not be official anyway.
> Personally I'd be happier if I can just lose rpm and deb targets
> from the "upstream" Makefile (git-core.spec file and debian/
> subdirectory as well while we are at it), ask "packaging
> maintainers" to pull from kernel.org/ tree and do RPMs and Debs
> outside.

I'd say you can probably keep the current setup, and as distro
(format?) specific maintainers show up and start maintaining bits and
pieces, merge from them. git should make that easy ;-)

I'm not a DD -- but I'm on the 'NM queue' which means I'm in the
process of turning into one (delayed at the moment, but hapenning
soonish). Have a package in the archive, and a few sponsors who are
generally happy to upload my work. Would be happy to give it a go if
noone else steps up.

(Sebastian _did_ indicate interest, and fought a long, hard battle in
debian-devel about the naming of the git and cg utilities. I haven't
seen him around lately (last post:
http://marc.theaimsgroup.com/?l=git&m=112747921603277&w=2 ). May be on
holiday? CC'd)

> On the other hand, having the basic support for packagers in the
> upstream might be easier for port maintainers.  I honestly do
> not know.

I think it'd be easier for all people involved if each port/packjage
maintainer keeps a published repo and you merge from them. Patches
have higher visibility and easier path towards "upstream".   
Maintainers want to keep the delta between their package and upstream
to the bare minimum.

> One thing we could do without breaking much of the current
> arrangement is to have a team of people to help porting for
> major packaging formats (RPMs and Debs mostly but I know we have
> OpenBSD and Darwin people here too), and ask them to feed me the
> updates to rpm/deb/whatever target in the Makefile as needed.

That's another good strategy. I suspect that you can push work towards
maintainers, so they publish 2 branches: one of forupstream patches
and one of 'local' patches. They have to do that anyway ;-)

cheers,


martin

Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)

[Linus Torvalds]

On Tue, 1 Nov 2005, Martin Langhoff wrote:
> >
> > git-core::
> >         All the rest, plus man pages.  We could separate out
> >         commit walkers if we wanted to, but I do not think that
> >         is necessary.
> 
> git-gitk ;-)

I really really prefer gitk in the core, even if it means that there's 
that strange tcl/tk dependency.

It's very small, and having something that visualizes what git does for 
people who don't understand git is _invaluable_. 

It wouldn't have to be gitk, but that's the least pain right now. qgit 
needs QT, which is much more contentious than tcl/tk. 

		Linus

Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)

[Martin Langhoff]

On 11/1/05, Linus Torvalds <torvalds@osdl.org> wrote:
> I really really prefer gitk in the core, even if it means that there's
> that strange tcl/tk dependency.

I agree, but that's kind of a bummer for servers where someone just
wants to publish a couple of repos. tk depends on xlibs/libx11 and
that's just _nasty_.

git-core should be good for deployment on a server. Perhaps we want to
provide a git-scm package that brings in all the goodies you're likely
to want, including gitk?


martin

Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)

[H. Peter Anvin]

Martin Langhoff wrote:
> 
> I agree, but that's kind of a bummer for servers where someone just
> wants to publish a couple of repos. tk depends on xlibs/libx11 and
> that's just _nasty_.
> 
> git-core should be good for deployment on a server. Perhaps we want to
> provide a git-scm package that brings in all the goodies you're likely
> to want, including gitk?
> 

How about calling it just "git"?

	-hpa

Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)

[David Lang]

On Tue, 1 Nov 2005, Martin Langhoff wrote:

> On 11/1/05, Linus Torvalds <torvalds@osdl.org> wrote:
>> I really really prefer gitk in the core, even if it means that there's
>> that strange tcl/tk dependency.
>
> I agree, but that's kind of a bummer for servers where someone just
> wants to publish a couple of repos. tk depends on xlibs/libx11 and
> that's just _nasty_.
>
> git-core should be good for deployment on a server. Perhaps we want to
> provide a git-scm package that brings in all the goodies you're likely
> to want, including gitk?

for debian make it a reccomendation not a requirement, for RPM the admins 
will just have to override the dependancy (it's not like they don't have 
to do this for a bunch of other packages that have an optional GUI piece, 
RPM just doesn't have the option to list a reccomendation)

David Lang

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)

[Sebastian Kuzminsky]

Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 11/1/05, Junio C Hamano <junkio@cox.net> wrote:
> > I am currently generating i386 RPMs and i386 debs myself but I
> > am not particularly proud of the current setup.  I do not have
> > an RPM based machine that I can install the result myself to
> > test (which is what started this thread).  Since I am not a
> > Debian developer (and I do not particularly wish to become one
> > myself), the debs I generate will not be official anyway.
> > Personally I'd be happier if I can just lose rpm and deb targets
> > from the "upstream" Makefile (git-core.spec file and debian/
> > subdirectory as well while we are at it), ask "packaging
> > maintainers" to pull from kernel.org/ tree and do RPMs and Debs
> > outside.
> 
> I'd say you can probably keep the current setup, and as distro
> (format?) specific maintainers show up and start maintaining bits and
> pieces, merge from them. git should make that easy ;-)
> 
> I'm not a DD -- but I'm on the 'NM queue' which means I'm in the
> process of turning into one (delayed at the moment, but hapenning
> soonish). Have a package in the archive, and a few sponsors who are
> generally happy to upload my work. Would be happy to give it a go if
> noone else steps up.
> 
> (Sebastian _did_ indicate interest, and fought a long, hard battle in
> debian-devel about the naming of the git and cg utilities. I haven't
> seen him around lately (last post:
> http://marc.theaimsgroup.com/?l=3Dgit&m=3D112747921603277&w=3D2 ). May be
> on holiday? CC'd)

I'm here :-)

The GNU Interactive Tools people are changing their name (to "gitfm"),
but they want a script called "git" to remind people that the name
has changed...  So I still have to rename our git to "gt" or something,
until they remove their git script.

We're going to use update-alternatives so people who dont care about
GNU Interactive Tools can call their git "git".  This is in violation
of Debian Policy, but I'm hoping my sponsor will forgive me, as it is
just a temporary violation.


I hope to get this work done sometime this week, and if I have anything
useful I'll send the patches to the list.


-- 
Sebastian Kuzminsky

Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)

[Junio C Hamano]

Martin Langhoff <martin.langhoff@gmail.com> writes:

> Perhaps git-tla-glue, git-cvs-glue, git-svn-glue, where glue stands
> for importers, exporters, tools, etc?

That sounds sensible.  Also I think not having to install xlib
on the repository server is an advantage as you said in your
reply to Linus.

So here is a revised strawman, just to keep things in one place:

git::
	Depends on all of the below (may not be necessary).

git-*-glue::
	Tools to interoperate with foreign SCM systems,
	including importing (i.e. obtaining changes from them)
	and exporting (i.e. injecting our changes into them).

git-doc::
	Generated documentation from Documentation hierarchy.

git-scm::
	Depends on git-gitk and git-core -- people who want just
	a self contained SCM can install this and perhaps
	git-doc.

git-gitk::
	The gitk history browser.

git-core::
	The rest.  Meant for repository server installation.

Package split: Debian.

[Junio C Hamano]

This is still WIP (I forgot to split out tla and doc) but I'd
appreciate it if somebody can help me on the RPM side.  An RPM
novice without a test install environment like myself is pretty
much useless for the job X-<.

Not that I am a Debian expert, but at least I do have a chrooted
sarge partition that I can test install and trash.

-- >8 -- cut here -- >8 --

As discussed on the list, split the foreign SCM interoperability
packages from the git-core binary package.

Signed-off-by: Junio C Hamano <junkio@cox.net>

---

 Makefile               |    4 ++--
 debian/changelog       |    7 +++++++
 debian/control         |   25 ++++++++++++++++++++++++-
 debian/git-cvs.files   |    2 ++
 debian/git-email.files |    2 ++
 debian/git-svn.files   |    2 ++
 debian/rules           |    5 ++++-
 7 files changed, 43 insertions(+), 4 deletions(-)
 create mode 100644 debian/git-cvs.files
 create mode 100644 debian/git-email.files
 create mode 100644 debian/git-svn.files

applies-to: 861aaf77ef8cff205f4d8721ce24f3c25d180ca8
0017ffa572ce837d0a73d69014a0f4820b2b80b5
diff --git a/Makefile b/Makefile
index 6064672..76d33b4 100644
--- a/Makefile
+++ b/Makefile
@@ -450,8 +450,8 @@ clean:
 	rm -f git-core.spec *.pyc *.pyo
 	rm -rf $(GIT_TARNAME)
 	rm -f $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz
-	rm -f git-core_$(GIT_VERSION)-*.deb git-core_$(GIT_VERSION)-*.dsc
-	rm -f git-tk_$(GIT_VERSION)-*.deb
+	rm -f git-core_$(GIT_VERSION)-*.dsc
+	rm -f git-*_$(GIT_VERSION)-*.deb
 	$(MAKE) -C Documentation/ clean
 	$(MAKE) -C templates clean
 	$(MAKE) -C t/ clean
diff --git a/debian/changelog b/debian/changelog
index 5fd31b7..17a4a24 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+git-core (0.99.9-1) unstable; urgency=low
+
+  * Split the git-core binary package into core and foreign SCM
+    interoperability modules.
+
+ -- Junio C Hamano <junkio@cox.net>  Sat, 29 Oct 2005 14:34:30 -0700
+
 git-core (0.99.9-0) unstable; urgency=low
 
   * GIT 0.99.9
diff --git a/debian/control b/debian/control
index 1f45f93..2c1d295 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Standards-Version: 3.6.1
 Package: git-core
 Architecture: any
 Depends: ${shlibs:Depends}, ${perl:Depends}, ${misc:Depends}, rcs
-Recommends: rsync, curl, ssh, libmail-sendmail-perl, libemail-valid-perl, libsvn-core-perl (>= 1.2.1), python (>= 2.4.0), less
+Recommends: rsync, curl, ssh, python (>= 2.4.0), less
 Suggests: cogito, patch
 Conflicts: git, cogito (<< 0.13)
 Description: The git content addressable filesystem
@@ -24,3 +24,26 @@ Depends: ${shlibs:Depends}, ${misc:Depen
 Description: The git content addressable filesystem, GUI add-on
  This package contains 'gitk', the git revision tree visualizer.
 
+Package: git-svn
+Architecture: all
+Depends: ${shlibs:Depends}, ${misc:Depends}, ${perl:Depends}, git-core, libsvn-core-perl (>= 1.2.1)
+Suggests: subversion
+Description: The git content addressable filesystem, SVN interoperability
+ This package contains 'git-svnimport', to import development history from
+ SVN repositories.
+
+Package: git-cvs
+Architecture: all
+Depends: ${shlibs:Depends}, ${misc:Depends}, ${perl:Depends}, git-core
+Suggests: cvs
+Description: The git content addressable filesystem, CVS interoperability
+ This package contains 'git-cvsimport', to import development history from
+ CVS repositories.
+
+Package: git-email
+Architecture: all
+Depends: ${shlibs:Depends}, ${misc:Depends}, git-core, libmail-sendmail-perl, libemail-valid-perl
+Description: The git content addressable filesystem, e-mail add-on
+ This package contains 'git-send-email', to send a series of patch e-mails.
+
+
diff --git a/debian/git-cvs.files b/debian/git-cvs.files
new file mode 100644
index 0000000..8bf5090
--- /dev/null
+++ b/debian/git-cvs.files
@@ -0,0 +1,2 @@
+/usr/bin/git-cvsimport
+/usr/share/doc/git-core/git-cvsimport.*
diff --git a/debian/git-email.files b/debian/git-email.files
new file mode 100644
index 0000000..236754c
--- /dev/null
+++ b/debian/git-email.files
@@ -0,0 +1,2 @@
+/usr/bin/git-send-email
+/usr/share/doc/git-core/git-send-email.*
diff --git a/debian/git-svn.files b/debian/git-svn.files
new file mode 100644
index 0000000..317b12a
--- /dev/null
+++ b/debian/git-svn.files
@@ -0,0 +1,2 @@
+/usr/bin/git-svnimport
+/usr/share/doc/git-core/git-svnimport.*
diff --git a/debian/rules b/debian/rules
index 568d430..cf33cdf 100755
--- a/debian/rules
+++ b/debian/rules
@@ -41,7 +41,7 @@ MAN_DESTDIR := $(DESTDIR)/$(MANDIR)
 build: debian/build-stamp
 debian/build-stamp:
 	dh_testdir
-	$(MAKE) prefix=$(PREFIX) PYTHON_PATH=/usr/bin/python2.4 all doc test
+	$(MAKE) prefix=$(PREFIX) PYTHON_PATH=/usr/bin/python2.4 all test doc
 	touch debian/build-stamp
 
 debian-clean:
@@ -65,7 +65,10 @@ install: build
 	mkdir -p $(DOC_DESTDIR)
 	find $(DOC) '(' -name '*.txt' -o -name '*.html' ')' -exec install {} $(DOC_DESTDIR) ';'
 
+	dh_movefiles -p git-cvs
+	dh_movefiles -p git-svn
 	dh_movefiles -p git-tk
+	dh_movefiles -p git-email
 	dh_movefiles -p git-core
 	find debian/tmp -type d -o -print | sed -e 's/^/? /'
 
---
0.99.9.GIT

Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)

[Horst von Brand]

Junio C Hamano <junkio@cox.net> wrote:

[...]

> I do not know much about how things are done in the RPM world,
> but is there a concept of "the upstream" vs "packaging
> maintainer" there?  IOW, are the majority of RPM binary packages
> done by the upstream maintainer?

No, they aren't. RPM is set up so you can take the vanilla upstream package
and add local patches, special configuration, ... at will downstream.
> 
> I am currently generating i386 RPMs and i386 debs myself but I
> am not particularly proud of the current setup.  I do not have
> an RPM based machine that I can install the result myself to
> test (which is what started this thread).  Since I am not a
> Debian developer (and I do not particularly wish to become one
> myself), the debs I generate will not be official anyway.
> Personally I'd be happier if I can just lose rpm and deb targets
> from the "upstream" Makefile (git-core.spec file and debian/
> subdirectory as well while we are at it), ask "packaging
> maintainers" to pull from kernel.org/ tree and do RPMs and Debs
> outside.

Please keep the git-core.spec file, it is useful to be able to build RPMs
directly from the tarball.

[...]

> One thing we could do without breaking much of the current
> arrangement is to have a team of people to help porting for
> major packaging formats (RPMs and Debs mostly but I know we have
> OpenBSD and Darwin people here too), and ask them to feed me the
> updates to rpm/deb/whatever target in the Makefile as needed.
> Especially before a major release I could ask them to test
> things out and generate binary packages, perhaps taken out of
> the tip of the master branch, or even another "for-porters"
> branch for this purpose.

Good idea. Will build RPMs regularly then.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)

[Junio C Hamano]

Horst von Brand <vonbrand@inf.utfsm.cl> writes:

> Junio C Hamano <junkio@cox.net> wrote:
>
>> One thing we could do without breaking much of the current
>> arrangement is to have a team of people to help porting for
>> major packaging formats (RPMs and Debs mostly but I know we have
>> OpenBSD and Darwin people here too), and ask them to feed me the
>> updates to rpm/deb/whatever target in the Makefile as needed.
>> Especially before a major release I could ask them to test
>> things out and generate binary packages, perhaps taken out of
>> the tip of the master branch, or even another "for-porters"
>> branch for this purpose.
>
> Good idea. Will build RPMs regularly then.

Can I take that to mean you are volunteering?