status of libgit.a
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): 20090219092446.23272.qmail@3b5a9fa637f270.315fe32.mid.smarden.org
Dear Git folks,
Am Donnerstag, den 19.02.2009, 09:24 +0000 schrieb Gerrit Pape:
Quoted 2 lines · Marc Oscar Singer
Quoted 1 line
Gerrit Pape wrote:
[…]
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
It depends on upstream. Back then, Junio asked to not provide such a library package in Debian, and I respect that. There've been some plans and effort to stabilize the lib in the past, but I'm not sure about the status.
Quoted 8 lines
Quoted 2 lines
Would it be a compromise to provide libgit.a as a static library for until it stabilizes?
That's not the compromise, that's the option, I don't know any plans about a shared library. The git-core-dev package that was available for short included such a static library.
You really need to talk to upstream if you want this libgit.a.
could you please give an update on the status of libgit.a. For example cgit still could not be packaged yet for Debian [1] because of this bug [2].
cgit is used by a lot of projects out there, so I am wondering if the current libgit.a can be released in its current state.
By the way, is there a web site/page for libgit.a?
Thanks and sorry if I got something wrong,
Paul
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515793
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407722
Quoted 8 lines · Paul Menzel
Quoted 1 line
You really need to talk to upstream if you want this libgit.a.
could you please give an update on the status of libgit.a. For example cgit still could not be packaged yet for Debian [1] because of this bug [2].
cgit is used by a lot of projects out there, so I am wondering if the current libgit.a can be released in its current state.
libgit.a is not a public library, so it will never have a stable API/ABI. There is a libgit2 project which tries to do this, but it's far from complete:
http://repo.or.cz/w/libgit2.git
Quoted 1 line
By the way, is there a web site/page for libgit.a?
No, there isn't.
I think the only sane solution is what Fedora does as well:
http://cvs.fedoraproject.org/viewvc/devel/cgit/
When cgit-1.2.3 is released, have a look at its Makefile, check what Git version does it want and add the relevant Git source to the cgit source package.
[ I remember Debian did not support having multiple upstream sources / one source package, I hope this is no longer the situation. ;-) ]
Quoted 7 lines · Miklos Vajna
I think the only sane solution is what Fedora does as well:
http://cvs.fedoraproject.org/viewvc/devel/cgit/
When cgit-1.2.3 is released, have a look at its
Makefile, check what Git version does it want and add the relevant Git source to the cgit source package.
Or bundle cgit with git.git as a subsystem, with Lars as maintainer.
Signature · 1 line
Duy
Quoted 9 lines · Paul Menzel
could you please give an update on the status of libgit.a. For example cgit still could not be packaged yet for Debian [1] because of this bug [2].
cgit is used by a lot of projects out there, so I am wondering if the current libgit.a can be released in its current state.
By the way, is there a web site/page for libgit.a?
libgit.a has never been meant to use outside of Git. It was created just to assist with the building process, and there is no clear defined API. So, using libgit.a outside of Git is no different than copying source files and using them in another project.
AFAIK, there is no plan to create a stable API for the existing libgit.a Another project (libgit2) started some time ago to create a Git library with a stable API, but it does not share much code with Git, and so far it provides only basic functionality and has very few contributors, who are also busy with other projects. So, in no way it can be considered as a replacement of existing libgit.a.
On the other hand, libgit.a includes plumbing functions, which may be considered as stable API. So, if cgit uses only those functions just to avoid fork(), it makes sense; but it should be done carefully, because libgit.a can call exit() on error. It may be not a problem for cgit, but it is just another reason why libgit.a cannot be considered as a general purpose library that provides Git functionality...
Dmitry
Hi,
Quoted 14 lines · Paul Menzel
Am Donnerstag, den 19.02.2009, 09:24 +0000 schrieb Gerrit Pape:
Quoted 2 lines · Marc Oscar Singer
Quoted 1 line
Gerrit Pape wrote:
[…]
Quoted 8 lines
Quoted 7 lines
Quoted 5 lines
It depends on upstream. Back then, Junio asked to not provide such a library package in Debian, and I respect that. There've been some plans and effort to stabilize the lib in the past, but I'm not sure about the status.
Would it be a compromise to provide libgit.a as a static library for until it stabilizes?
Quoted 7 lines
Quoted 5 lines
That's not the compromise, that's the option, I don't know any plans about a shared library. The git-core-dev package that was available for short included such a static library.
You really need to talk to upstream if you want this libgit.a.
could you please give an update on the status of libgit.a.
There had been some people who worked towards a re-entrant libgit.a (read:
non-die()ing in library functions). But there were too many others, so that effort stopped.
The most likely route for people needing libgit.a would be libgit2:
http://git.wiki.kernel.org/index.php/SoC2010Ideas#Complete_libgit2
Quoted 2 lines
For example cgit still could not be packaged yet for Debian [1] because of this bug [2].
cgit should not depend on libgit.a, as it is linked statically anyway.
Ciao,
Dscho