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

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Oct 31, 2005, 20:13 UTC
Message-ID: <46a038f90510311213n565010d6g5586a7484b25da7e@mail.gmail.com>
In-Reply-To: <7v4q6xfpqg.fsf@assigned-by-dhcp.cox.net>

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

> git-tla-import, git-cvs-import, git-svn-import, ...::
>         Importers, one per foreign SCMs.

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.

Show 7 quoted lines

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

git-gitk ;-)

Show 11 quoted lines

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

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)

> On the other hand, having the basic support for packagers in the
> upstream might be easier for port maintainers.  I honestly do
> not know.

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.

Show 5 quoted lines

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

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