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. -- bye, pabs https://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part