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

"H. Peter Anvin" [off-list ref] 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 took Ryan's suggestion and pushed 0.99.9a out.  Does it make
RHEL4 happy?

* Junio C Hamano (junkio@cox.net) wrote:

"H. Peter Anvin" [off-list ref] writes:

quoted

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 took Ryan's suggestion and pushed 0.99.9a out.  Does it make
RHEL4 happy?

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

	-hpa

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

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

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:

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. 

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" [off-list ref] writes:

Chris Wright wrote:

quoted

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.

Junio C Hamano wrote:

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?

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 [off-list ref] 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.

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 ;-)

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.

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

On Tue, 1 Nov 2005, Martin Langhoff wrote:

quoted

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 ;-)

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

Martin Langhoff [off-list ref] wrote:

On 11/1/05, Junio C Hamano [off-list ref] wrote:

quoted

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=3Dgit&m=3D112747921603277&w=3D2 ). May be
on holiday? CC'd)

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.


-- 
Sebastian Kuzminsky

On 11/1/05, Linus Torvalds [off-list ref] wrote:

I really really prefer gitk in the core, even if it means that there's
that strange tcl/tk dependency.

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:

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?

How about calling it just "git"?

	-hpa

On Tue, 1 Nov 2005, Martin Langhoff wrote:

On 11/1/05, Linus Torvalds [off-list ref] wrote:

quoted

I really really prefer gitk in the core, even if it means that there's
that strange tcl/tk dependency.

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?

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

-- 
There 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.
  -- C.A.R. Hoare