Hi,
I have been investigating the differences of "upstream release tarball"
versus "upstream git tag/github tarball" and I noticed that "upstream
release" differs a bit:
(1) Release tarball ships .c files compiled from python sources with
cython (examples: borg/crypto.c, borg/chunker.c)
(2) Release tarball includes generated generates .rst.inc files for
documentation by calling
borg help <topic> (see script docs/update_usage.sh)
(3) Release tarball includes a static borg/_version.py, while git tag
includes one embedding the git revision.
I personally think we should regenerate (1) with debian's packaged
cython3 during the build instead of using the upstream ones.
Rationale for this is mainly security: If any serious bug is discovered
in cython3, and we call it during build, all we need is a
no-change-rebuild in order to benefit from the fix. [This will mainly
get relevant when borgbackup reaches "stable" and upstream has moved on]
While (2) and (3) are nowhere near as important as (1), if we recreate
those ourselves during the build process, we could simply depend on
upstream git tag releases (those are gpg-signed with the same key as the
release tarball btw).
I am generally assuming that the (git-)versioned files are the only
actual human-written sources, and everything else is generated by
automation. I would suggest Debian imports only the human-written source
code, and we run all automation following it at build-time.
I am currently working on a proof-of-concept version of d/rules doing
all of that, I will report back here once I've got a working draft.
Of course, in the end, this is just my personal opinion and not
necessarily required policy, however 4.13 ("Convenience copies of code",
although this discusses included *library* code) suggests a similar
direction. I could not find anything on "including generated files vs.
regenerating them" in general.
https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
- Danny
