{"thread":{"id":"2277","subject":"git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)","startedAt":"2005-10-30T20:12:36Z","lastAt":"2005-11-05T11:19:51Z","messageCount":24,"participants":["H. Peter Anvin","Wolfgang Denk","Junio C Hamano","Ryan Anderson","Chris Wright","Linus Torvalds","Martin Langhoff","Sebastian Kuzminsky","David Lang"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"10819","messageId":"43652934.8000308@zytor.com","threadId":"2277","inReplyTo":null,"subject":"git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-10-30T20:12:36Z","receivedAt":"2005-10-30T20:12:36Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"The Subversion importer Perl script breaks RPM generation.  First of \nall, it introduces new module dependencies which don't exist in for \nexample RHEL4.  The easiest way to deal with that is probably to fork \noff the subversion exporter into a separate package, but the really bad \none is:\n\ngit-svnimport.perl:require v5.8.0; # for shell-safe open(\"-|\",LIST)\n\n... which RPM thinks means that you need a Perl module called v5.8.0 \nwhich doesn't, of course, exist.  This is arguably an rpmbuild bug, but \nit nevertheless breaks at the moment.\n\nI'm afraid I cannot update any of the kernel.org machines to 0.99.9 \nuntil these problems have been cleaned up.\n\n\t-hpa\n"},{"id":"10822","messageId":"20051030204034.849C5353E3E@atlas.denx.de","threadId":"2277","inReplyTo":"43652934.8000308@zytor.com","subject":"Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)","fromName":"Wolfgang Denk","fromEmail":"wd@denx.de","sentAt":"2005-10-30T20:40:34Z","receivedAt":"2005-10-30T20:40:34Z","isPatch":false,"sender":{"key":"wd@denx.de","avatar":null},"body":"In message <43652934.8000308@zytor.com> you wrote:\n> The Subversion importer Perl script breaks RPM generation.  First of \n\nConfirmed. Well, actually the RPM *build* works fine.\n\n> ... which RPM thinks means that you need a Perl module called v5.8.0 \n> which doesn't, of course, exist.  This is arguably an rpmbuild bug, but \n> it nevertheless breaks at the moment.\n\nIt's when trying to install the RPM that we get:\n\nerror: Failed dependencies:\n        perl(v5.8.0) is needed by git-core-0.99.9-1.i386\n\n\nBest regards,\n\nWolfgang Denk\n\n-- \nSoftware Engineering:  Embedded and Realtime Systems,  Embedded Linux\nPhone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de\n\"There are things that are so serious that you can  only  joke  about\nthem\"                                                    - Heisenberg\n"},{"id":"10824","messageId":"43653248.2010608@zytor.com","threadId":"2277","inReplyTo":"20051030204034.849C5353E3E@atlas.denx.de","subject":"Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-10-30T20:51:20Z","receivedAt":"2005-10-30T20:51:20Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Wolfgang Denk wrote:\n> In message <43652934.8000308@zytor.com> you wrote:\n> \n>>The Subversion importer Perl script breaks RPM generation.  First of \n> \n> Confirmed. Well, actually the RPM *build* works fine.\n\nNo, it doesn't.  It runs to completion, but it produces the wrong output.\n\n\t-hpa\n"},{"id":"10827","messageId":"7v1x22odka.fsf@assigned-by-dhcp.cox.net","threadId":"2277","inReplyTo":"43652934.8000308@zytor.com","subject":"Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-30T22:16:53Z","receivedAt":"2005-10-30T22:16:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" <hpa@zytor.com> writes:\n\n> git-svnimport.perl:require v5.8.0; # for shell-safe open(\"-|\",LIST)\n>\n> ... which RPM thinks means that you need a Perl module called v5.8.0 \n> which doesn't, of course, exist.  This is arguably an rpmbuild bug, but \n> it nevertheless breaks at the moment.\n>\n> I'm afraid I cannot update any of the kernel.org machines to 0.99.9 \n> until these problems have been cleaned up.\n\nFair enough.  We'd work it around just like we handle\nsend-email.\n"},{"id":"10828","messageId":"436548F3.1030507@michonline.com","threadId":"2277","inReplyTo":"43652934.8000308@zytor.com","subject":"Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2005-10-30T22:28:03Z","receivedAt":"2005-10-30T22:28:03Z","isPatch":false,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"H. Peter Anvin wrote:\n> The Subversion importer Perl script breaks RPM generation.  First of\n> all, it introduces new module dependencies which don't exist in for\n> example RHEL4.  The easiest way to deal with that is probably to fork\n> off the subversion exporter into a separate package, but the really bad\n> one is:\n> \n> git-svnimport.perl:require v5.8.0; # for shell-safe open(\"-|\",LIST)\n> \n> ... which RPM thinks means that you need a Perl module called v5.8.0\n> which doesn't, of course, exist.  This is arguably an rpmbuild bug, but\n> it nevertheless breaks at the moment.\n\nIf you change that to the traditional statement of \"require 5.008;\",\ndoes it fix things up?\n"},{"id":"10830","messageId":"7vll0amy1z.fsf_-_@assigned-by-dhcp.cox.net","threadId":"2277","inReplyTo":"7v1x22odka.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] Do not try installing SVNimport on RPM","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-30T22:37:12Z","receivedAt":"2005-10-30T22:37:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"HPA reports that svnimport uses perl 5.8.4 and the syntax it\nuses to require confuses rpmbuild.  So let's try demoting the\nproblematic script just like we do with send-email.\n\nSomebody should supply tested patches to split the package or\nwhatever is needed if they want to use these scripts on RPM\nbased systems.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n\n---\n\n     \"H. Peter Anvin\" <hpa@zytor.com> writes:\n\n    > git-svnimport.perl:require v5.8.0; # for shell-safe open(\"-|\",LIST)\n    >\n    > ... which RPM thinks means that you need a Perl module called v5.8.0 \n    > which doesn't, of course, exist.  This is arguably an rpmbuild bug, but \n    > it nevertheless breaks at the moment.\n    >\n    > I'm afraid I cannot update any of the kernel.org machines to 0.99.9 \n    > until these problems have been cleaned up.\n\n    Does this work for you?\n\n Makefile         |   10 ++++++++--\n debian/changelog |    6 ++++++\n debian/rules     |    3 ++-\n git.sh           |    1 +\n 4 files changed, 17 insertions(+), 3 deletions(-)\n\napplies-to: 5d3fb770835ba710480cbaf0c1b076a3a4affc54\ne217a63c79ad93b26cb816eede1baf34e27b1e61\ndiff --git a/Makefile b/Makefile\nindex 1163dda..c60fb6b 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -52,7 +52,7 @@\n \n # DEFINES += -DUSE_STDEV\n \n-GIT_VERSION = 0.99.9.GIT\n+GIT_VERSION = 0.99.9a\n \n CFLAGS = -g -O2 -Wall\n ALL_CFLAGS = $(CFLAGS) $(PLATFORM_DEFINES) $(DEFINES)\n@@ -94,7 +94,7 @@ SCRIPT_SH = \\\n SCRIPT_PERL = \\\n \tgit-archimport.perl git-cvsimport.perl git-relink.perl \\\n \tgit-rename.perl git-shortlog.perl git-fmt-merge-msg.perl \\\n-\tgit-findtags.perl git-svnimport.perl git-mv.perl\n+\tgit-findtags.perl git-mv.perl\n \n SCRIPT_PYTHON = \\\n \tgit-merge-recursive.py\n@@ -142,6 +142,12 @@ else\n \tGIT_LIST_TWEAK += -e '/^send-email$$/d'\n endif\n \n+ifdef WITH_SVNIMPORT\n+\tSCRIPT_PERL += git-svnimport.perl\n+else\n+\tGIT_LIST_TWEAK += -e '/^svnimport$$/d'\n+endif\n+\n LIB_FILE=libgit.a\n \n LIB_H = \\\ndiff --git a/debian/changelog b/debian/changelog\nindex 5fd31b7..5c5ba55 100644\n--- a/debian/changelog\n+++ b/debian/changelog\n@@ -1,3 +1,9 @@\n+git-core (0.99.9a-0) unstable; urgency=low\n+\n+  * GIT 0.99.9a\n+\n+ -- Junio C Hamano <junkio@cox.net>  Sun, 30 Oct 2005 14:30:03 -0800\n+\n git-core (0.99.9-0) unstable; urgency=low\n \n   * GIT 0.99.9\ndiff --git a/debian/rules b/debian/rules\nindex 568d430..e6b6bad 100755\n--- a/debian/rules\n+++ b/debian/rules\n@@ -26,8 +26,9 @@ else\n endif\n \n # We do have the requisite perl modules in the mainline, and\n-# have no reason to shy away from this script.\n+# have no reason to shy away from these scripts.\n export WITH_SEND_EMAIL=YesPlease\n+export WITH_SVNIMPORT=YesPlease\n \n PREFIX := /usr\n MANDIR := /usr/share/man/\ndiff --git a/git.sh b/git.sh\nindex 94940ae..cd800bc 100755\n--- a/git.sh\n+++ b/git.sh\n@@ -70,6 +70,7 @@ send-email\n shortlog\n show-branch\n status\n+svnimport\n tag\n verify-tag\n whatchanged\n---\n0.99.9.GIT\n"},{"id":"10832","messageId":"7vzmoqlict.fsf@assigned-by-dhcp.cox.net","threadId":"2277","inReplyTo":"436548F3.1030507@michonline.com","subject":"Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-30T23:01:38Z","receivedAt":"2005-10-30T23:01:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ryan Anderson <ryan@michonline.com> writes:\n\n>> git-svnimport.perl:require v5.8.0; # for shell-safe open(\"-|\",LIST)\n>> \n>> ... which RPM thinks means that you need a Perl module called v5.8.0\n>> which doesn't, of course, exist.  This is arguably an rpmbuild bug, but\n>> it nevertheless breaks at the moment.\n>\n> If you change that to the traditional statement of \"require 5.008;\",\n> does it fix things up?\n\nAh, I like that better.  Let me try that.\n"},{"id":"10835","messageId":"7vd5lmlgl9.fsf@assigned-by-dhcp.cox.net","threadId":"2277","inReplyTo":"43654F4B.30103@zytor.com","subject":"Re: [PATCH] Do not try installing SVNimport on RPM","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-30T23:39:46Z","receivedAt":"2005-10-30T23:39:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This is based on Ryan's suggestion.  Running 'rpm --requires'\non the resulting RPM  seems to want these -- which I cannot\njudge if this would be something that satisfies you.  I'd push\nit out if it is OK with you.\n\nAlso I do not see \"use v5.8.0\" you mentioned in a separate\nmessage anywhere in the tree, so I am hoping that should be OK.\n\njunio@hera:~/git(0)$ R=~/rpms/RPMS/i386/git-core-0.99.9a-1.i386.rpm\njunio@hera:~/git(0)$ rpm -q -i -p $R --requires | grep 'perl '\n/usr/bin/perl\nperl >= 0:5.006\nperl >= 0:5.008\njunio@hera:~/git(0)$ exit\n\n ------------\n[PATCH] Work around an RPM build problem.\n\nThe require statement at the top of git-svnimport seems to confuse\nrpmbuild dependency generation.  It uses the newer notation \"v5.8.0\",\nand rpm ends up requiring \"perl(v5.8.0)\", while we would want it to\nsay something like \"perl >= 0:5.008\".\n\nRyan suggests old-style \"require 5.008\" might fix this problem, so\nhere it is.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n\n---\n\n git-svnimport.perl |    2 +-\n Makefile           |    2 +-\n debian/changelog   |    6 ++++++\n 3 files changed, 8 insertions(+), 2 deletions(-)\n\napplies-to: 5d3fb770835ba710480cbaf0c1b076a3a4affc54\nc846e15ee31b7226a715646f633fc1fdd2e14cd9\ndiff --git a/git-svnimport.perl b/git-svnimport.perl\nindex 20a8572..45b6a19 100755\n--- a/git-svnimport.perl\n+++ b/git-svnimport.perl\n@@ -10,7 +10,7 @@\n # The head revision is on branch \"origin\" by default.\n # You can change that with the '-o' option.\n \n-require v5.8.0; # for shell-safe open(\"-|\",LIST)\n+require 5.008; # for shell-safe open(\"-|\",LIST)\n use strict;\n use warnings;\n use Getopt::Std;\ndiff --git a/Makefile b/Makefile\nindex 1163dda..5bb5108 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -52,7 +52,7 @@\n \n # DEFINES += -DUSE_STDEV\n \n-GIT_VERSION = 0.99.9.GIT\n+GIT_VERSION = 0.99.9a\n \n CFLAGS = -g -O2 -Wall\n ALL_CFLAGS = $(CFLAGS) $(PLATFORM_DEFINES) $(DEFINES)\ndiff --git a/debian/changelog b/debian/changelog\nindex 5fd31b7..7d18483 100644\n--- a/debian/changelog\n+++ b/debian/changelog\n@@ -1,3 +1,9 @@\n+git-core (0.99.9a-0) unstable; urgency=low\n+\n+  * GIT 0.99.9a\n+\n+ -- Junio C Hamano <junkio@cox.net>  Sun, 30 Oct 2005 15:03:32 -0800\n+\n git-core (0.99.9-0) unstable; urgency=low\n \n   * GIT 0.99.9\n---\n0.99.9.GIT\n"},{"id":"10843","messageId":"7vy84ajl4c.fsf@assigned-by-dhcp.cox.net","threadId":"2277","inReplyTo":"43652934.8000308@zytor.com","subject":"Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-31T05:44:51Z","receivedAt":"2005-10-31T05:44:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" <hpa@zytor.com> writes:\n\n> git-svnimport.perl:require v5.8.0; # for shell-safe open(\"-|\",LIST)\n>\n> ... which RPM thinks means that you need a Perl module called v5.8.0 \n> which doesn't, of course, exist.  This is arguably an rpmbuild bug, but \n> it nevertheless breaks at the moment.\n\nI took Ryan's suggestion and pushed 0.99.9a out.  Does it make\nRHEL4 happy?\n"},{"id":"10845","messageId":"20051031064105.GV8041@shell0.pdx.osdl.net","threadId":"2277","inReplyTo":"7vy84ajl4c.fsf@assigned-by-dhcp.cox.net","subject":"Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)","fromName":"Chris Wright","fromEmail":"chrisw@osdl.org","sentAt":"2005-10-31T06:41:05Z","receivedAt":"2005-10-31T06:41:05Z","isPatch":false,"sender":{"key":"chrisw@sous-sol.org","avatar":null},"body":"* Junio C Hamano (junkio@cox.net) wrote:\n> \"H. Peter Anvin\" <hpa@zytor.com> writes:\n> \n> > git-svnimport.perl:require v5.8.0; # for shell-safe open(\"-|\",LIST)\n> >\n> > ... which RPM thinks means that you need a Perl module called v5.8.0 \n> > which doesn't, of course, exist.  This is arguably an rpmbuild bug, but \n> > it nevertheless breaks at the moment.\n> \n> I took Ryan's suggestion and pushed 0.99.9a out.  Does it make\n> RHEL4 happy?\n\nIt's fine for FC3.  Certain irony that git now effectively requires\nsubversion.  I'm all for splitting these out, but have no time until\nlater in the week.  BTW, mind pushing the tag?\n\nthanks,\n-chris\n"},{"id":"10844","messageId":"7vsluiji5i.fsf@assigned-by-dhcp.cox.net","threadId":"2277","inReplyTo":"20051031064105.GV8041@shell0.pdx.osdl.net","subject":"Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-31T06:48:57Z","receivedAt":"2005-10-31T06:48:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Chris Wright <chrisw@osdl.org> writes:\n\n> It's fine for FC3.  Certain irony that git now effectively requires\n> subversion.\n\nHaha.\n\n> BTW, mind pushing the tag?\n\nDone; thanks for noticing.\n"},{"id":"10852","messageId":"43663EEA.5050102@zytor.com","threadId":"2277","inReplyTo":"20051031064105.GV8041@shell0.pdx.osdl.net","subject":"Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-10-31T15:57:30Z","receivedAt":"2005-10-31T15:57:30Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Chris Wright wrote:\n> \n> It's fine for FC3.  Certain irony that git now effectively requires\n> subversion.  I'm all for splitting these out, but have no time until\n> later in the week.  BTW, mind pushing the tag?\n> \n\nThe git-core RPM definitiely needs to be split.  Doubly ironic that it's \ncalled \"core\".\n\n\t-hpa\n"},{"id":"10856","messageId":"Pine.LNX.4.64.0510310819290.27915@g5.osdl.org","threadId":"2277","inReplyTo":"43663EEA.5050102@zytor.com","subject":"Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-10-31T16:25:21Z","receivedAt":"2005-10-31T16:25:21Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 31 Oct 2005, H. Peter Anvin wrote:\n> \n> The git-core RPM definitiely needs to be split.  Doubly ironic that it's\n> called \"core\".\n\nI don't think it's necessarily ironic. It's actually a good thing.\n\nI think that what we want to have is one _project_ (called \"git\"), which \ncan generate multiple RPM's (\"git-core\", \"git-svnimport\", \"git-docs\", \nwhatever).\n\nSo I think it was good that we called the RPM \"git-core\". We've just not \nyet done the obvious thing to create a few _other_ RPM's.\n\nNow, I'm not certain how happy RPM would be with having one source RPM \ngenerate multiple binary RPM's, so we might have problems with some stupid \nRPM rules, but I think we should really do this. There's always going to \nbe some extra feature that not everybody needs, but that it would be silly \nto have its own project for. \n\nHaving one bigger project means that it's much easier to maintain, and \nthere's less administrative overhead (good maintainers are really hard to \nfind: you should realize how lucky we are to have Junio). Trying to split \nup the source code into independent projects at this level would just be \nmuch more pain than it's worth. But clearly we want to split up the RPM's.\n\n\t\tLinus\n"},{"id":"10857","messageId":"436645D6.3050506@zytor.com","threadId":"2277","inReplyTo":"Pine.LNX.4.64.0510310819290.27915@g5.osdl.org","subject":"Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-10-31T16:27:02Z","receivedAt":"2005-10-31T16:27:02Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Linus Torvalds wrote:\n> \n> Now, I'm not certain how happy RPM would be with having one source RPM \n> generate multiple binary RPM's, so we might have problems with some stupid \n> RPM rules, but I think we should really do this. There's always going to \n> be some extra feature that not everybody needs, but that it would be silly \n> to have its own project for. \n> \n\nRPM is more than happy to do this.  It's a standard feature of RPM.  The \ncurrent RPM, however, is structured in a way that makes it somewhat \npainful, as it depends a little too much on wildcards.\n\n\t-hpa\n"},{"id":"10866","messageId":"7v4q6xfpqg.fsf@assigned-by-dhcp.cox.net","threadId":"2277","inReplyTo":"43663EEA.5050102@zytor.com","subject":"Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-31T19:31:03Z","receivedAt":"2005-10-31T19:31:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" <hpa@zytor.com> writes:\n\n> Chris Wright wrote:\n>> It's fine for FC3.  Certain irony that git now effectively requires\n>> subversion.  I'm all for splitting these out, but have no time until\n>> later in the week.  BTW, mind pushing the tag?\n>\n> The git-core RPM definitiely needs to be split.  Doubly ironic that it's \n> called \"core\".\n\nBTW, did that \"require 5.008\" change make the resulting package\nRPM happy on RH-EL4?\n\nI agree that it is an extremely good thing to split the binary\npackages into separate ones so that the system administrators\ncan pick and choose only the bits that are needed.  Here is a\nstrawman:\n\ngit-tla-import, git-cvs-import, git-svn-import, ...::\n\tImporters, one per foreign SCMs.\n\ngit-docs::\n\tGenerated documentation from Documentation hierarchy.\n\ngit-core::\n        All the rest, plus man pages.  We could separate out\n\tcommit walkers if we wanted to, but I do not think that\n\tis necessary.\n\nHaving said that, I consider this purely binary packaging issue.\nI.e. I do not think you are advocating for splitting the source\ntree.\n\nI do not know much about how things are done in the RPM world,\nbut is there a concept of \"the upstream\" vs \"packaging\nmaintainer\" there?  IOW, are the majority of RPM binary packages\ndone by the upstream maintainer?\n\nI am currently generating i386 RPMs and i386 debs myself but I\nam not particularly proud of the current setup.  I do not have\nan RPM based machine that I can install the result myself to\ntest (which is what started this thread).  Since I am not a\nDebian developer (and I do not particularly wish to become one\nmyself), the debs I generate will not be official anyway.\nPersonally I'd be happier if I can just lose rpm and deb targets\nfrom the \"upstream\" Makefile (git-core.spec file and debian/\nsubdirectory as well while we are at it), ask \"packaging\nmaintainers\" to pull from kernel.org/ tree and do RPMs and Debs\noutside.\n\nOn the other hand, having the basic support for packagers in the\nupstream might be easier for port maintainers.  I honestly do\nnot know.\n\nOne thing we could do without breaking much of the current\narrangement is to have a team of people to help porting for\nmajor packaging formats (RPMs and Debs mostly but I know we have\nOpenBSD and Darwin people here too), and ask them to feed me the\nupdates to rpm/deb/whatever target in the Makefile as needed.\nEspecially before a major release I could ask them to test\nthings out and generate binary packages, perhaps taken out of\nthe tip of the master branch, or even another \"for-porters\"\nbranch for this purpose.\n"},{"id":"10867","messageId":"43667227.9090606@zytor.com","threadId":"2277","inReplyTo":"7v4q6xfpqg.fsf@assigned-by-dhcp.cox.net","subject":"Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-10-31T19:36:07Z","receivedAt":"2005-10-31T19:36:07Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> \n> I do not know much about how things are done in the RPM world,\n> but is there a concept of \"the upstream\" vs \"packaging\n> maintainer\" there?  IOW, are the majority of RPM binary packages\n> done by the upstream maintainer?\n> \n\nIt does both ways.  I think Chris Wright has been doing the formal \nmaintenance of RPM for Fedora.\n\nLatency is an issue, though, especially for kernel.org.\n\n\t-hpa\n"},{"id":"10872","messageId":"46a038f90510311213n565010d6g5586a7484b25da7e@mail.gmail.com","threadId":"2277","inReplyTo":"7v4q6xfpqg.fsf@assigned-by-dhcp.cox.net","subject":"Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-10-31T20:13:41Z","receivedAt":"2005-10-31T20:13:41Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 11/1/05, Junio C Hamano <junkio@cox.net> wrote:\n> git-tla-import, git-cvs-import, git-svn-import, ...::\n>         Importers, one per foreign SCMs.\n\nI concur generally with the plan, except that I think we should wrap\nthe import/export scripts together(*). One-script-per-package is\npretty awkward, and yet the dependencies for a\ngit-export-import-scripts packages are going to be awful as they'll\noften pull a whole raft of SCMs.\n\nHmmm.\n\nPerhaps git-tla-glue, git-cvs-glue, git-svn-glue, where glue stands\nfor importers, exporters, tools, etc?\n\n*- I'm starting to think that the script to replay git commits into\ncvs that I posted last week (cleaned up patch coming soon)  should\nfollow the git-cvsimport convertion and be something along the lines\nof git-cvsexportpatch, to be followed by git-cvsexport which would\nautomate discovering what patches need exporting and drive\ngit-cvsexportpatch.\n\n> git-docs::\n>         Generated documentation from Documentation hierarchy.\n>\n> git-core::\n>         All the rest, plus man pages.  We could separate out\n>         commit walkers if we wanted to, but I do not think that\n>         is necessary.\n\ngit-gitk ;-)\n\n> I am currently generating i386 RPMs and i386 debs myself but I\n> am not particularly proud of the current setup.  I do not have\n> an RPM based machine that I can install the result myself to\n> test (which is what started this thread).  Since I am not a\n> Debian developer (and I do not particularly wish to become one\n> myself), the debs I generate will not be official anyway.\n> Personally I'd be happier if I can just lose rpm and deb targets\n> from the \"upstream\" Makefile (git-core.spec file and debian/\n> subdirectory as well while we are at it), ask \"packaging\n> maintainers\" to pull from kernel.org/ tree and do RPMs and Debs\n> outside.\n\nI'd say you can probably keep the current setup, and as distro\n(format?) specific maintainers show up and start maintaining bits and\npieces, merge from them. git should make that easy ;-)\n\nI'm not a DD -- but I'm on the 'NM queue' which means I'm in the\nprocess of turning into one (delayed at the moment, but hapenning\nsoonish). Have a package in the archive, and a few sponsors who are\ngenerally happy to upload my work. Would be happy to give it a go if\nnoone else steps up.\n\n(Sebastian _did_ indicate interest, and fought a long, hard battle in\ndebian-devel about the naming of the git and cg utilities. I haven't\nseen him around lately (last post:\nhttp://marc.theaimsgroup.com/?l=git&m=112747921603277&w=2 ). May be on\nholiday? CC'd)\n\n> On the other hand, having the basic support for packagers in the\n> upstream might be easier for port maintainers.  I honestly do\n> not know.\n\nI think it'd be easier for all people involved if each port/packjage\nmaintainer keeps a published repo and you merge from them. Patches\nhave higher visibility and easier path towards \"upstream\".   \nMaintainers want to keep the delta between their package and upstream\nto the bare minimum.\n\n> One thing we could do without breaking much of the current\n> arrangement is to have a team of people to help porting for\n> major packaging formats (RPMs and Debs mostly but I know we have\n> OpenBSD and Darwin people here too), and ask them to feed me the\n> updates to rpm/deb/whatever target in the Makefile as needed.\n\nThat's another good strategy. I suspect that you can push work towards\nmaintainers, so they publish 2 branches: one of forupstream patches\nand one of 'local' patches. They have to do that anyway ;-)\n\ncheers,\n\n\nmartin\n"},{"id":"10874","messageId":"Pine.LNX.4.64.0510311230290.27915@g5.osdl.org","threadId":"2277","inReplyTo":"46a038f90510311213n565010d6g5586a7484b25da7e@mail.gmail.com","subject":"Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-10-31T20:32:21Z","receivedAt":"2005-10-31T20:32:21Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 1 Nov 2005, Martin Langhoff wrote:\n> >\n> > git-core::\n> >         All the rest, plus man pages.  We could separate out\n> >         commit walkers if we wanted to, but I do not think that\n> >         is necessary.\n> \n> git-gitk ;-)\n\nI really really prefer gitk in the core, even if it means that there's \nthat strange tcl/tk dependency.\n\nIt's very small, and having something that visualizes what git does for \npeople who don't understand git is _invaluable_. \n\nIt wouldn't have to be gitk, but that's the least pain right now. qgit \nneeds QT, which is much more contentious than tcl/tk. \n\n\t\tLinus\n"},{"id":"10875","messageId":"E1EWgRc-0003ME-Rg@highlab.com","threadId":"2277","inReplyTo":"46a038f90510311213n565010d6g5586a7484b25da7e@mail.gmail.com","subject":"Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)","fromName":"Sebastian Kuzminsky","fromEmail":"seb@highlab.com","sentAt":"2005-10-31T20:39:52Z","receivedAt":"2005-10-31T20:39:52Z","isPatch":false,"sender":{"key":"seb@highlab.com","avatar":"https://gravatar.com/avatar/f7ddd092ba3cf6999434f4d0d2f4b90fd174c2c3851617e8cffc0a2fee47becc?d=mp&s=160"},"body":"Martin Langhoff <martin.langhoff@gmail.com> wrote:\n> On 11/1/05, Junio C Hamano <junkio@cox.net> wrote:\n> > I am currently generating i386 RPMs and i386 debs myself but I\n> > am not particularly proud of the current setup.  I do not have\n> > an RPM based machine that I can install the result myself to\n> > test (which is what started this thread).  Since I am not a\n> > Debian developer (and I do not particularly wish to become one\n> > myself), the debs I generate will not be official anyway.\n> > Personally I'd be happier if I can just lose rpm and deb targets\n> > from the \"upstream\" Makefile (git-core.spec file and debian/\n> > subdirectory as well while we are at it), ask \"packaging\n> > maintainers\" to pull from kernel.org/ tree and do RPMs and Debs\n> > outside.\n> \n> I'd say you can probably keep the current setup, and as distro\n> (format?) specific maintainers show up and start maintaining bits and\n> pieces, merge from them. git should make that easy ;-)\n> \n> I'm not a DD -- but I'm on the 'NM queue' which means I'm in the\n> process of turning into one (delayed at the moment, but hapenning\n> soonish). Have a package in the archive, and a few sponsors who are\n> generally happy to upload my work. Would be happy to give it a go if\n> noone else steps up.\n> \n> (Sebastian _did_ indicate interest, and fought a long, hard battle in\n> debian-devel about the naming of the git and cg utilities. I haven't\n> seen him around lately (last post:\n> http://marc.theaimsgroup.com/?l=3Dgit&m=3D112747921603277&w=3D2 ). May be\n> on holiday? CC'd)\n\nI'm here :-)\n\nThe GNU Interactive Tools people are changing their name (to \"gitfm\"),\nbut they want a script called \"git\" to remind people that the name\nhas changed...  So I still have to rename our git to \"gt\" or something,\nuntil they remove their git script.\n\nWe're going to use update-alternatives so people who dont care about\nGNU Interactive Tools can call their git \"git\".  This is in violation\nof Debian Policy, but I'm hoping my sponsor will forgive me, as it is\njust a temporary violation.\n\n\nI hope to get this work done sometime this week, and if I have anything\nuseful I'll send the patches to the list.\n\n\n-- \nSebastian Kuzminsky\n"},{"id":"10876","messageId":"46a038f90510311244n5fc35166k43ea2410e92d83d4@mail.gmail.com","threadId":"2277","inReplyTo":"Pine.LNX.4.64.0510311230290.27915@g5.osdl.org","subject":"Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-10-31T20:44:24Z","receivedAt":"2005-10-31T20:44:24Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 11/1/05, Linus Torvalds <torvalds@osdl.org> wrote:\n> I really really prefer gitk in the core, even if it means that there's\n> that strange tcl/tk dependency.\n\nI agree, but that's kind of a bummer for servers where someone just\nwants to publish a couple of repos. tk depends on xlibs/libx11 and\nthat's just _nasty_.\n\ngit-core should be good for deployment on a server. Perhaps we want to\nprovide a git-scm package that brings in all the goodies you're likely\nto want, including gitk?\n\n\nmartin\n"},{"id":"10877","messageId":"43668299.60603@zytor.com","threadId":"2277","inReplyTo":"46a038f90510311244n5fc35166k43ea2410e92d83d4@mail.gmail.com","subject":"Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-10-31T20:46:17Z","receivedAt":"2005-10-31T20:46:17Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Martin Langhoff wrote:\n> \n> I agree, but that's kind of a bummer for servers where someone just\n> wants to publish a couple of repos. tk depends on xlibs/libx11 and\n> that's just _nasty_.\n> \n> git-core should be good for deployment on a server. Perhaps we want to\n> provide a git-scm package that brings in all the goodies you're likely\n> to want, including gitk?\n> \n\nHow about calling it just \"git\"?\n\n\t-hpa\n"},{"id":"10880","messageId":"7vpsplcr7l.fsf@assigned-by-dhcp.cox.net","threadId":"2277","inReplyTo":"46a038f90510311213n565010d6g5586a7484b25da7e@mail.gmail.com","subject":"Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-31T21:27:26Z","receivedAt":"2005-10-31T21:27:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Langhoff <martin.langhoff@gmail.com> writes:\n\n> Perhaps git-tla-glue, git-cvs-glue, git-svn-glue, where glue stands\n> for importers, exporters, tools, etc?\n\nThat sounds sensible.  Also I think not having to install xlib\non the repository server is an advantage as you said in your\nreply to Linus.\n\nSo here is a revised strawman, just to keep things in one place:\n\ngit::\n\tDepends on all of the below (may not be necessary).\n\ngit-*-glue::\n\tTools to interoperate with foreign SCM systems,\n\tincluding importing (i.e. obtaining changes from them)\n\tand exporting (i.e. injecting our changes into them).\n\ngit-doc::\n\tGenerated documentation from Documentation hierarchy.\n\ngit-scm::\n\tDepends on git-gitk and git-core -- people who want just\n\ta self contained SCM can install this and perhaps\n\tgit-doc.\n\ngit-gitk::\n\tThe gitk history browser.\n\ngit-core::\n\tThe rest.  Meant for repository server installation.\n"},{"id":"10882","messageId":"Pine.LNX.4.62.0510311330050.16906@qynat.qvtvafvgr.pbz","threadId":"2277","inReplyTo":"46a038f90510311244n5fc35166k43ea2410e92d83d4@mail.gmail.com","subject":"Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)","fromName":"David Lang","fromEmail":"dlang@digitalinsight.com","sentAt":"2005-10-31T21:31:33Z","receivedAt":"2005-10-31T21:31:33Z","isPatch":false,"sender":{"key":"dlang@digitalinsight.com","avatar":null},"body":"On Tue, 1 Nov 2005, Martin Langhoff wrote:\n\n> On 11/1/05, Linus Torvalds <torvalds@osdl.org> wrote:\n>> I really really prefer gitk in the core, even if it means that there's\n>> that strange tcl/tk dependency.\n>\n> I agree, but that's kind of a bummer for servers where someone just\n> wants to publish a couple of repos. tk depends on xlibs/libx11 and\n> that's just _nasty_.\n>\n> git-core should be good for deployment on a server. Perhaps we want to\n> provide a git-scm package that brings in all the goodies you're likely\n> to want, including gitk?\n\nfor debian make it a reccomendation not a requirement, for RPM the admins \nwill just have to override the dependancy (it's not like they don't have \nto do this for a bunch of other packages that have an optional GUI piece, \nRPM just doesn't have the option to list a reccomendation)\n\nDavid Lang\n\n-- \nThere 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.\n  -- C.A.R. Hoare\n"},{"id":"11168","messageId":"7v7jbnpciw.fsf_-_@assigned-by-dhcp.cox.net","threadId":"2277","inReplyTo":"7vpsplcr7l.fsf@assigned-by-dhcp.cox.net","subject":"Package split: Debian.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-05T11:19:51Z","receivedAt":"2005-11-05T11:19:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This is still WIP (I forgot to split out tla and doc) but I'd\nappreciate it if somebody can help me on the RPM side.  An RPM\nnovice without a test install environment like myself is pretty\nmuch useless for the job X-<.\n\nNot that I am a Debian expert, but at least I do have a chrooted\nsarge partition that I can test install and trash.\n\n-- >8 -- cut here -- >8 --\n\nAs discussed on the list, split the foreign SCM interoperability\npackages from the git-core binary package.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n\n---\n\n Makefile               |    4 ++--\n debian/changelog       |    7 +++++++\n debian/control         |   25 ++++++++++++++++++++++++-\n debian/git-cvs.files   |    2 ++\n debian/git-email.files |    2 ++\n debian/git-svn.files   |    2 ++\n debian/rules           |    5 ++++-\n 7 files changed, 43 insertions(+), 4 deletions(-)\n create mode 100644 debian/git-cvs.files\n create mode 100644 debian/git-email.files\n create mode 100644 debian/git-svn.files\n\napplies-to: 861aaf77ef8cff205f4d8721ce24f3c25d180ca8\n0017ffa572ce837d0a73d69014a0f4820b2b80b5\ndiff --git a/Makefile b/Makefile\nindex 6064672..76d33b4 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -450,8 +450,8 @@ clean:\n \trm -f git-core.spec *.pyc *.pyo\n \trm -rf $(GIT_TARNAME)\n \trm -f $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz\n-\trm -f git-core_$(GIT_VERSION)-*.deb git-core_$(GIT_VERSION)-*.dsc\n-\trm -f git-tk_$(GIT_VERSION)-*.deb\n+\trm -f git-core_$(GIT_VERSION)-*.dsc\n+\trm -f git-*_$(GIT_VERSION)-*.deb\n \t$(MAKE) -C Documentation/ clean\n \t$(MAKE) -C templates clean\n \t$(MAKE) -C t/ clean\ndiff --git a/debian/changelog b/debian/changelog\nindex 5fd31b7..17a4a24 100644\n--- a/debian/changelog\n+++ b/debian/changelog\n@@ -1,3 +1,10 @@\n+git-core (0.99.9-1) unstable; urgency=low\n+\n+  * Split the git-core binary package into core and foreign SCM\n+    interoperability modules.\n+\n+ -- Junio C Hamano <junkio@cox.net>  Sat, 29 Oct 2005 14:34:30 -0700\n+\n git-core (0.99.9-0) unstable; urgency=low\n \n   * GIT 0.99.9\ndiff --git a/debian/control b/debian/control\nindex 1f45f93..2c1d295 100644\n--- a/debian/control\n+++ b/debian/control\n@@ -8,7 +8,7 @@ Standards-Version: 3.6.1\n Package: git-core\n Architecture: any\n Depends: ${shlibs:Depends}, ${perl:Depends}, ${misc:Depends}, rcs\n-Recommends: rsync, curl, ssh, libmail-sendmail-perl, libemail-valid-perl, libsvn-core-perl (>= 1.2.1), python (>= 2.4.0), less\n+Recommends: rsync, curl, ssh, python (>= 2.4.0), less\n Suggests: cogito, patch\n Conflicts: git, cogito (<< 0.13)\n Description: The git content addressable filesystem\n@@ -24,3 +24,26 @@ Depends: ${shlibs:Depends}, ${misc:Depen\n Description: The git content addressable filesystem, GUI add-on\n  This package contains 'gitk', the git revision tree visualizer.\n \n+Package: git-svn\n+Architecture: all\n+Depends: ${shlibs:Depends}, ${misc:Depends}, ${perl:Depends}, git-core, libsvn-core-perl (>= 1.2.1)\n+Suggests: subversion\n+Description: The git content addressable filesystem, SVN interoperability\n+ This package contains 'git-svnimport', to import development history from\n+ SVN repositories.\n+\n+Package: git-cvs\n+Architecture: all\n+Depends: ${shlibs:Depends}, ${misc:Depends}, ${perl:Depends}, git-core\n+Suggests: cvs\n+Description: The git content addressable filesystem, CVS interoperability\n+ This package contains 'git-cvsimport', to import development history from\n+ CVS repositories.\n+\n+Package: git-email\n+Architecture: all\n+Depends: ${shlibs:Depends}, ${misc:Depends}, git-core, libmail-sendmail-perl, libemail-valid-perl\n+Description: The git content addressable filesystem, e-mail add-on\n+ This package contains 'git-send-email', to send a series of patch e-mails.\n+\n+\ndiff --git a/debian/git-cvs.files b/debian/git-cvs.files\nnew file mode 100644\nindex 0000000..8bf5090\n--- /dev/null\n+++ b/debian/git-cvs.files\n@@ -0,0 +1,2 @@\n+/usr/bin/git-cvsimport\n+/usr/share/doc/git-core/git-cvsimport.*\ndiff --git a/debian/git-email.files b/debian/git-email.files\nnew file mode 100644\nindex 0000000..236754c\n--- /dev/null\n+++ b/debian/git-email.files\n@@ -0,0 +1,2 @@\n+/usr/bin/git-send-email\n+/usr/share/doc/git-core/git-send-email.*\ndiff --git a/debian/git-svn.files b/debian/git-svn.files\nnew file mode 100644\nindex 0000000..317b12a\n--- /dev/null\n+++ b/debian/git-svn.files\n@@ -0,0 +1,2 @@\n+/usr/bin/git-svnimport\n+/usr/share/doc/git-core/git-svnimport.*\ndiff --git a/debian/rules b/debian/rules\nindex 568d430..cf33cdf 100755\n--- a/debian/rules\n+++ b/debian/rules\n@@ -41,7 +41,7 @@ MAN_DESTDIR := $(DESTDIR)/$(MANDIR)\n build: debian/build-stamp\n debian/build-stamp:\n \tdh_testdir\n-\t$(MAKE) prefix=$(PREFIX) PYTHON_PATH=/usr/bin/python2.4 all doc test\n+\t$(MAKE) prefix=$(PREFIX) PYTHON_PATH=/usr/bin/python2.4 all test doc\n \ttouch debian/build-stamp\n \n debian-clean:\n@@ -65,7 +65,10 @@ install: build\n \tmkdir -p $(DOC_DESTDIR)\n \tfind $(DOC) '(' -name '*.txt' -o -name '*.html' ')' -exec install {} $(DOC_DESTDIR) ';'\n \n+\tdh_movefiles -p git-cvs\n+\tdh_movefiles -p git-svn\n \tdh_movefiles -p git-tk\n+\tdh_movefiles -p git-email\n \tdh_movefiles -p git-core\n \tfind debian/tmp -type d -o -print | sed -e 's/^/? /'\n \n---\n0.99.9.GIT\n"}]}