On Tue, 08 Sep 2015 09:23:51 -0400 Antoine Beaupré wrote: > > How does it differ from the package that Gianfranco and Marc have been > working on? (In cc.) > > A.
It doesn't necessarily "differ" in the sense that it would be a different from-scratch packaging. It is 95% their package, plus a few lines in d/rules and one patch in d/patches to accomodate for the differences between upstream git and upstream tarball. My Idea was that instead of just saying "regenerate those files" I wanted to add a stance saying "and it could work somewhat like this", in order to have a discussion on whether my Idea makes sense, and not on the basis of whether it even works. The only differences are: (1) Repository layout "branch off the main repo" I didn't use upstream tarball, but rather depended only on the git tag (which doesn't contain the generated files I spoke of earlier, but it contains the code to re-generate them) Basically I followed this: http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.UPSTREAM.GIT.NOTARBALL (2) Rebuilding .c and .rst.inc files By using the upstream git directly, we can use the upstream build system (which already calls cython and sphinx) to generate the .c sources and the .rst.inc for the html manual. Some environment-variable-setting in d/rules was necessary to call the upstream docs/Makefile, to make sure it can call "borg help COMMAND --usage-only" during the generation of the .rst.inc files. (3) Patch to remove travis and codecov badges README.rst in git contains images that say "code coverage xyz%" and "travis build [passing/failing]". I didn't think they are of relevance to a Debian user (since they reflect current git status, not the version installed) plus it may be a privacy concern to load external resources when browsing the local copy of the manual. I also think that by using upstream git directly, we get the advantage of directly being able to use git-bisect/git-cherry-pick for identifying and backporting fixes to the stable version, which may come in handy later on. Danny
