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

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

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html