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

In message <43652934.8000308@zytor.com> you wrote:

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

Wolfgang Denk wrote:

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

	-hpa

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

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.

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

H. Peter Anvin wrote:

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

Ryan Anderson <ryan@michonline.com> writes:

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

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

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

* Junio C Hamano (junkio@cox.net) 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?

thanks, -chris

Chris Wright <chrisw@osdl.org> writes:

Haha.

Done; thanks for noticing.

Chris Wright wrote:

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

	-hpa

On Mon, 31 Oct 2005, H. Peter Anvin wrote:

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

Linus Torvalds wrote:

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

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

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 wrote:

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

On 11/1/05, Junio C Hamano <junkio@cox.net> wrote:

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

On Tue, 1 Nov 2005, Martin Langhoff wrote:

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

On 11/1/05, Linus Torvalds <torvalds@osdl.org> 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?

martin

Martin Langhoff wrote:

How about calling it just "git"?

	-hpa

On Tue, 1 Nov 2005, Martin Langhoff wrote:

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

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

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.

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

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.

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

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