Re: Rebuilds with unexpected timestamps
On Mon, 31 Oct 2016 at 00:38:22 +0200, Adrian Bunk wrote:
> The "hello" package still builds after you autoreconf the package,
> but the program no longer knows what version it is (automake tries to
> run build-aux/git-version-gen which is not in the source tarball).
I think that's an upstream bug: git-version-gen is written in such
a way that it can be run from either git or a tarball (where it will
use ./.tarball-version). Its canonical upstream appears to be GNU
coreutils, which does seem to distribute it in tarballs.
> If you want this to work properly, Debian has to move from using the
> generated release tarballs to the actual source in the upstream VCS.
Encouraging upstreams to put complete-enough source in tarball releases
would be sufficient; but before opening bugs, I'd recommend asking
yourself which category the missing files are in:
* "Obviously required": present in both git and tarball and required
for compilation (e.g. *.[ch]). Omitting these from the tarball is
clearly a rather severe upstream bug. If the files are only *sometimes*
required for compilation (e.g. tests' source code, or test scripts
without which tests fail) then it's a less severe bug but still a
bug. I'd suggest sending patches upstream to add these to EXTRA_DIST
(I had to do this for some ostree tests recently).
* Source for generated files in the tarball: should be in both git and
tarball, but sometimes mistakenly omitted from tarballs (e.g. configure.ac,
m4/foo.m4, build-aux/git-version-gen). Leaving these out of the tarball is
also an upstream bug, IMO, because it means the "source" tarball
is not really its own source. I'd suggest sending patches upstream to
add these to EXTRA_DIST.
* Non-essential extras: non-essential files like Valgrind suppressions,
extra documentation, alternative build systems. Depending whether they
are practically useful, leaving these out of the tarball release is
potentially an upstream bug, but if it is, it's often a relatively
minor one. I'd suggest considering how much benefit these files give
before opening bugs; if the files are genuinely useful, send patches
upstream, but if the benefit is mostly theoretical, taking up the
maintainer's time and attention with this might not be the best idea.
* Things that are useless when not dealing with git: .gitignore,
.gitattributes, git.mk (.gitignore generator) as used in e.g.
some GNOME projects, .arcconfig when using Phabricator. There's little
point in asking upstreams to include these, because they would serve
little or no purpose when not in a git checkout; trying would probably
just annoy your upstreams.
Regards,
S
Reply to: