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

From: Junio C Hamano <junkio@cox.net>
Date: Oct 31, 2005, 19:31 UTC
Message-ID: <7v4q6xfpqg.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <43663EEA.5050102@zytor.com>

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

Show 7 quoted lines

> 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.