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

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

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

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: [email protected]
"There are things that are so serious that you can  only  joke  about
them"                                                    - Heisenberg

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

-hpa

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.

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

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.

---

"H. Peter Anvin" <[email protected]> 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

index 1163dda..c60fb6b 100644
@@ -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 = \

index 5fd31b7..5c5ba55 100644
@@ -1,3 +1,9 @@
+git-core (0.99.9a-0) unstable; urgency=low
+
+  * GIT 0.99.9a
+
+ -- Junio C Hamano <[email protected]>  Sun, 30 Oct 2005 14:30:03 -0800
+
 git-core (0.99.9-0) unstable; urgency=low
 
   * GIT 0.99.9

index 568d430..e6b6bad 100755
@@ -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/

index 94940ae..cd800bc 100755
@@ -70,6 +70,7 @@ send-email
 shortlog
 show-branch
 status
+svnimport
 tag
 verify-tag
 whatchanged

---
0.99.9.GIT

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.

---

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

applies-to: 5d3fb770835ba710480cbaf0c1b076a3a4affc54 c846e15ee31b7226a715646f633fc1fdd2e14cd9

index 20a8572..45b6a19 100755
@@ -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;

index 1163dda..5bb5108 100644
@@ -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)

index 5fd31b7..7d18483 100644
@@ -1,3 +1,9 @@
+git-core (0.99.9a-0) unstable; urgency=low
+
+  * GIT 0.99.9a
+
+ -- Junio C Hamano <[email protected]>  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

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

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

-hpa

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.

Junio C Hamano <[email protected]> wrote:

[...]

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.

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

[...]

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

Can I take that to mean you are volunteering?

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

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-gitk ;-)

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)

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.

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

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.

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.

---

 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

index 6064672..76d33b4 100644
@@ -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

index 5fd31b7..17a4a24 100644
@@ -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 <[email protected]>  Sat, 29 Oct 2005 14:34:30 -0700
+
 git-core (0.99.9-0) unstable; urgency=low
 
   * GIT 0.99.9

index 1f45f93..2c1d295 100644
@@ -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.
+
+

new file mode 100644
index 0000000..8bf5090
@@ -0,0 +1,2 @@
+/usr/bin/git-cvsimport
+/usr/share/doc/git-core/git-cvsimport.*

new file mode 100644
index 0000000..236754c
@@ -0,0 +1,2 @@
+/usr/bin/git-send-email
+/usr/share/doc/git-core/git-send-email.*

new file mode 100644
index 0000000..317b12a
@@ -0,0 +1,2 @@
+/usr/bin/git-svnimport
+/usr/share/doc/git-core/git-svnimport.*

index 568d430..cf33cdf 100755
@@ -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

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

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

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

How about calling it just "git"?

-hpa

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

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

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

Right.

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

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

Haha.

Done; thanks for noticing.