On 8/16/21 3:18 AM, Paul Wise wrote:
> Hi all,
>
> I noticed that sometimes Debian's choice of upstream source for
> packaging can be suboptimal. This is especially apparent for the
> different per-language upstream packaging ecosystems[1], where the
> upstream packaging differs from the upstream VCS in some significant
> ways, including missing files, prebuilt files, embedded copies etc.
>
> While the upstream VCS also sometimes has these issues, it is often
> much less problematic than the upstream packaging ecosystems.
>
> I'd like to suggest that we standardise on the upstream VCS for our
> orig.tar.gz files and phase out use of upstream packaging ecosystems.
>
> For packages where the upstream packaging uses a tarball and it is
> accompanied by an OpenPGP signature, and the differences between the
> upstream VCS and the tarball aren't too problematic, we could use the
> tarball in preference to the VCS due to having a signature.
>
> While discussing PyPI with the Python team, it was pointed out that
> sometimes the tarball contains things that cannot be regenerated from
> just the VCS snapshot, such as information stored in the VCS history,
> so perhaps the recommendation should be to prefer the VCS but always
> compare the VCS with upstream tarballs and packaging ecosystem tarballs
> using diffoscope in order to discover differences important to Debian.
>
> I'd also like to see upstream tarball export systems switch to plain
> VCS exports plus additional tarballs for files like autotools cruft.
>
> If there is rough consensus we could add lintian complaints when Debian
> watch files or copyright source locations refer to these ecosystems.
>
> 1. the ecosystems I'm talking about include cargo, npm, browser
> extensions, rubygems, pypi, CPAN etc.
+1 to deprecate PyPi links.
It's been *years* since I encounter a PyPi package that doesn't have a
Git repo as its homepage (and unfortunately, 99% on Github).
I wrote this many times, but I don't see why we should use any "upstream
tarball" when the Git repository itself contains the tarball with:
git archive --prefix=$(DEBPKGNAME)-$(VERSION)/ $(GIT_TAG) \
| xz >../$(DEBPKGNAME)_$(VERSION).orig.tar.xz
(which leads to a .xz, which is nicer)
Not only then, only only has to merge the upstream tag in the Debian
branch to get the new release, but on top, no need to "gbp import" or
"pristine-tar commit", and a single packaging branch becomes enough.
I very much wish this packaging workflow gained more traction, and the
pristine-tar abomination dies...
Cheers,
Thomas Goirand (zigo)
