Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided upstream source tarballs
On Fri, Jun 25, 2021 at 11:42 PM Jeremy Stanley wrote:
> 1. Cryptographically signed tags in a Git repository, with
> versioning, revision history, release notes and authorship either
> embedded within or tied to the Git metadata.
> 2. Cryptographically signed tarballs of the file tree corresponding
> to a tag in the Git repository, with versioning, revision
> history, release notes and authorship extracted into files
> included directly within the tarball.
I would like to see #2 split into two separate tarballs, one for the
exact copy of the git tree and one containing the data about the other
tarball. Then use dpkg-source v3 secondary tarballs to add the data
about the git repo to the Debian source package.
> Saying that a raw dump of the file content from a revision control
> system is recommended over using upstream's sdists presumes all
> upstreams are the same. They're not, and which is preferable (or
> doable, or even legal) differs from one to another. Just because
> some sdists, or even many, are not suitable as a basis for packaging
> doesn't mean that sdists are a bad idea to base packages on. Yes,
> basing packages on bad sdists is bad, it's hard to disagree with
Probably we should start systematically comparing upstream VCS repos
with upstream sdists and reacting to the differences. So far, I've
reacted by ignoring the sdists completely.