On Sun, Jul 29, 2012 at 9:20 PM, Jonathan Nieder <jrnie...@gmail.com> wrote:
> Hi Marc, > > Marc Singer wrote: > > On Sun, Jul 29, 2012 at 6:36 PM, Jonathan Nieder <jrnie...@gmail.com> > wrote: > > >> Did you mean this to be a private reply? > > > > Not really. > > Ok, cc-ing the bug. > > [...] > > The policy of the git authors is their prerogative. They've made it very > > clear that they will not support a shared library. I suppose if you > could > > manage the SO as part of the debian packages. Doing so puts the burden > on > > us to track API changes with no promised from upstream. > > > > Is this what you are proposing? > > You're presumably thinking of <http://bugs.debian.org/407722>. > > No, I agree with Gerrit and think that shipping libgit.a as a library > is a non-starter. Git's internal APIs (that's what libgit.a is) are > very unstable, and to provide it as a package, even with a constantly > changing name, would be to make an interface promise we couldn't keep. > > Instead, I was offering to build cgit from the *same* source package > as git. I would probably try to upstream the change (putting a > submodule with cgit under contrib/), but even if upstream does not > accept it, we could build cgit in Debian this way. > > The main (and only) advantage of this approach is that when an API > break causes cgit to stop working, git would FTBFS. This immediate > feedback would force the code to keep working together. > > Hoping that clarifies, > Jonathan > > Sounds like a good plan. Do you need my help?
