On 2014-08-16 16:28:40 +0800 (+0800), Thomas Goirand wrote:
[...]
> If I prefer to use their git repository, and create my
> own orig.tar.xz out of a signed git tag, what is the problem, as
> long as I use the tag they provided by upstream?
[...]
Mainly that the checksums for your orig.tar.{g,x}z will differ from
those in upstream's signed release announcement, and also that you
may miss changes in upstream's dist-build tooling (though in general
I would hope upstreams maintain a _very_ stable interface for things
like 'make dist').
> Is there some sort of religion around tarballs?
No moreso than there's a "religion" around git tags I suppose--but
I'm not keen on getting into religious debates. The fact of the
matter is that you're packaging software for a distribution which
uses tarballs as part of its source packaging format and has
established conventions around them.
> Shouldn't it be the same stuff that "git archive" does? If it
> isn't, why is this the case? Shouldn't one be able to use what's
> in the Git repository anyway? Why can't it be fixed?
For a variety of historical and pragmatic reasons, many distribution
channels expect a release tarball to contain some information which
is more efficiently stored in VCS metadata (authorship, detailed
change information, version numbers, et cetera). As a result,
keeping that data in files within a VCS as well as in VCS metadata
is double-entry and more subject to drift/inconsistency.
In this case I think having a dist build step is a "solution" rather
than a "problem" which needs "fixing." I work on some very large
projects where it was established as extremely error-prone to
maintain this information by hand in two places (not a theoretical
problem but an actual observed mistake made sufficiently often to
warrant directly addressing in our release processes and tooling).
> Isn't the upstream git repository the "preferred form for
> modification", closer to what someone should be using when
> contributing upstream?
I think this is twisting DFSG #2 pretty substantially to claim that
a tarball containing a few additional autogenerated metadata files
from a make dist step is somehow less free than one created by
tarring up files directly out of a VCS branch. If upstream's VCS
really is "the preferred form for modification" (which BTW is
wording borrowed from the GPL and doesn't appear in DFSG #2
directly), then Debian is effectively *not* distributing the
preferred form regardless--the currently accepted source package
formats in fact make that impossible (format 3.0-git went nowhere
due to ftp-master review concerns, and even it still used tarballs
for its underlying file archive though that was more of an
implementation detail).
> Why is it the case that upstream prefers that we use something
> generated from his git repository?
In some ways it's nice if multiple distributions (most of whom to
this day base their various source package formats on release
tarballs) could have consistent checksums for easier comparison, but
that's more of a nice-to-have given that a lot of them pick
different upstream releases to package long-term. The bigger reason
is that when every distribution picks a different way to regenerate
the tarball they inevitably use for their packaging, they often get
it wrong by reimplementing the source dist build step themselves
without an understanding of the original intent.
> Shouldn't all what upstream generates in the release tarball also
> done by the Debian package build anyway?
You're free to do so (is regenerating authors lists, changelogs, et
cetera during package build really worth the effort?), but the point
of contention is that if you're not going to use the *actual*
release tarball provided by upstream and are instead making a new
one yourself from the VCS, this is effectively the same as
repacking. If you repack an upstream tarball, isn't it convention to
annotate the version you're claiming on it to indicate it's been
repacked (and include a readme.source file or similar documenting
your repacking methodology)? I'm merely suggesting that if you're
going to generate "original" tarballs from VCS contents then they
should be treated in a similar fashion as a repacked tarball in that
regard.
> Also, what if I need to build a Debian package out of an upstream
> commit, because there's some bug fixes which I need, but there's
> no upstream tarball available?
[...]
As already mentioned in my message to which you're replying here,
it's understandable that you might generate substitute tarballs
out of a VCS when there is no corresponding release tarball, for
example when packaging development snapshots. However reinventing
upstream's dist steps to make the tarball you eventually end up
using in your source package anyway seems like a duplication of
effort.
> If by "traditional release process" you mean wasting human time,
> computer CPU, and network bandwidth, to build old 80ies fashioned
> tarballs (that is: with .gz compression and no PGP checksums),
> which by the way loose all the commit history and such, I am
> wondering what you are worrying about. That's useless these days,
> if upstream is using Git. A tag is enough, and it's even better.
[...]
I recall it suggested on Debian mailing lists and other
howtos/articles even in very recent years that to be a "good
upstream" you should release tarballs and publish signed release
announcements including their checksums, and that upstreams who only
"release" software as a tag in a VCS are making things harder for
everyone downstream. Pretty much all the projects on which I do
upstream work provide these things because they have been explicitly
requested by distribution packagers.
If the modern trend is to just assume that nobody upstream will
bother to release tarballs any longer and expect every distribution
to do it themselves only slightly differently, then I should revisit
those assumptions and perhaps no longer bother. Is this a generally
consistent opinion across Debian package maintainers now? Across
other distributions as well?
> I also think it's best to be able to build from the git repository
> rather than what's been generated out of it, because that's what you
> will do if you want to contribute to the upstream project.
Makes sense. So then why does Debian (and for that matter so many
other distributions outside of the *BSDs) base source packages on
tarballs rather than building binary packages directly out of a VCS?
It seems a contradiction on the one hand to assert that you don't
need tarballs any longer but then on the other hand still rely on
them completely.
--
Jeremy Stanley
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140818204021.gv1...@yuggoth.org
