Bug#515793: ITP: CGIT -- C-code Web Front-end to GIT
Hi,
On 04-08-13 00:59, Jonathan Nieder wrote:
I'd like to propse another solution for this: let git build a git-source
binary package, and build cgit using that package.
I would prefer not to go this way. It would mean that when I make git
uploads, they'd always have a chance of breaking the cgit build
without notice. And it would also mean that whenever I fix an
important bug I have to track down whether cgit needs to be rebuilt.
Yes, that's true. (Unfortunately Debian doesn't have CI-infrastructure
available to rebuild cgit on all commits to the git package. I think that
could have been a good compromise).
An alternative that is not as bad is to export libgit.a (or .so, for
that matter) and headers for cgit use.
Wouldn't exporting the static library suffer from the same problems as
exporting the source? cgit will still need to be rebuild to profit from bug
fixes in git, and git can still break its build without notice. Exporting
the shared library would of course prevent the first problem. However, some
of the discussion in #407722 indicated that git upstream doesn't want libgit
to be exported, and the Debian maintainers didn't want to overrule them. If
that has changed, great :)
I think git breaking cgit's build isn't that big of a problem. cgit upstream
seems to be active enough in fixing compatiblity with newer git versions,
and the required changes are in general quite small (upgrade from 1.7.7.4 to
1.8.3 required just 6 lines of code in total). So if you don't have a
problem with exporting libgit anymore, I think that's the way we should go,
and I'll create cgit packages using them.
I'd far prefer to just have a copy of cgit built as part of the git
build. It doesn't have to involve multiple upstream tarballs: e.g.,
cgit can be included in the debian/ directory in the debian.tar.xz in
the short term, and in the long term I think it would be a candidate
for inclusion in contrib/ upstream.
Building two projects with separate release cycles and upstreams from the
same source package just feels wrong to me, and I prefer to not do it,
especially as the git package already seems quite complex.
> All that said, if someone wants to add another binary package like
> git-source to the git build and is willing to maintain it in the long
> term, I'll be glad to help (and wash my hands of the day-to-day
> maintenance :)).
>
> See /usr/share/doc/git/README.source for hints on working with the
> package. Packaging is at git://git.debian.org/~jrnieder-guest/git.git
I'll take a stab at doing that. Maintaining it long-term shouldn't be a problem.
(fyi, the Vcs-* fields in the package indicate another repository. Might be
useful to synchronize the repositories and/or changes the Vcs-* fields.)
Cheers,
Oxan
Reply to: