Path: csiph.com!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!bofh.it!news.nic.it!robomod From: Jeremy Stanley Newsgroups: linux.debian.maint.python Subject: Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided upstream source tarballs Date: Sat, 26 Jun 2021 06:20:02 +0200 Message-ID: References: X-Original-To: debian-python@lists.debian.org X-Mailbox-Line: From debian-python-request@lists.debian.org Sat Jun 26 04:19:03 2021 Old-Return-Path: X-Amavis-Spam-Status: No, score=-10.334 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, LDO_WHITELIST=-5, PGPSIGNATURE=-5, SARE_BOUNDARY_LC=1.666] autolearn=ham autolearn_force=no X-Policyd-Weight: using cached result; rate: -4.6 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vybvstwjxqtvcrmg" Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) X-Sa-Exim-Connect-IP: 2001:4802:7801:102:be76:4eff:fe20:63e0 X-Sa-Exim-Rcpt-To: debian-python@lists.debian.org X-Sa-Exim-Mail-From: fungi@yuggoth.org X-Sa-Exim-Scanned: No (on azathoth.yuggoth.org); SAEximRunCond expanded to false X-Mailing-List: archive/latest/19240 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/20210626041844.ovl7jubliipk2sw2@yuggoth.org Approved: robomod@news.nic.it Lines: 88 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Sat, 26 Jun 2021 04:18:44 +0000 X-Original-Message-ID: <20210626041844.ovl7jubliipk2sw2@yuggoth.org> X-Original-References: <877dihvfp9.fsf@DigitalMercury.dynalias.net> <20210625211721.eluslf3hee5eug7r@yuggoth.org> <877dihd1ds.fsf@DigitalMercury.dynalias.net> <20210625234144.vwfjk6xprvqzscx3@yuggoth.org> Xref: csiph.com linux.debian.maint.python:13450 --vybvstwjxqtvcrmg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-06-26 02:04:40 +0000 (+0000), Paul Wise wrote: > On Fri, Jun 25, 2021 at 11:42 PM Jeremy Stanley wrote: [..] > > 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. >=20 > 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. [...] You might like to see them split, but why is the exact copy of the work tree the only legitimate way to export data from a Git repository? Adding egg-info to the tarball creates a *Python Source Distribution* which is a long-standing standard method for distributing source code of Python software. Those files could even be checked directly into the repository, so that the work tree was itself also a valid sdist. The only reason the projects I work on don't do that is because some of it would be redundant with the metadata from the revision control system. You could of course create your own split tarballs of the work tree and the additional metadata files, but to what end? If upstream is already delivering them together in a release tarball, how is making your own beneficial when it still has to be done by the package maintainer before assembling the source package? Users of Debian don't benefit, because they still can't recreate your split tarball if they wanted without also having a copy of the upstream Git repository anyway. It just seems like make-work. > 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. I highly recommend it. We explicitly test that our sdists don't omit files from the Git worktree (sans .git* files like .gitignore and =2Egitreview which make no sense outside the context of a Git repository). On the other hand, I've found at least one case where a copyright statement in a Debian package refers to an AUTHORS file shipped as part of the sdist, but since the maintainer chose to package it from Git instead and did not generate that file when doing so, it's not included in the packaged version distributed in Debian. (Not linking the bug report here as I don't want it to seem like I'm picking on the maintainer.) Just to reiterate, as an upstream we don't consider the work trees of our Git repos to be complete source distributions. They can be used along with the versioning and history tracked as part of the repository to generate a complete source distribution, and that's what we officially release. Downstream distributions are encouraged to either use our release tarballs or clones of our Git repositories to recreate the same files we would release, but if you choose to do neither of those you're likely to miss something. --=20 Jeremy Stanley --vybvstwjxqtvcrmg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAABCgB9FiEEl65Jb8At7J/DU7LnSPmWEUNJWCkFAmDWqpFfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 QUU0OTZGQzAyREVDOUZDMzUzQjJFNzQ4Rjk5NjExNDM0OTU4MjkACgkQSPmWEUNJ WCmtVRAAvrHG+MPaoZkrchnWafa4KWJGOd8O3ayV0r67A8afEbl0rYK5d5ifaG4M B11Fn1klZaGAEIoXJEpmelgjwVtXsEVJ+mDHIi8ljEc573h3W4nMUQLi1Ntugqhu 2hs+e9hBV6nOL3/XE0qfGA4MrQiB6c13kl8tgzaZ4rj8PH5b0wLQdvfCY2OvtTKv kgKgOwFoLZ7h5lV/i3YrQsSnqBCm48TFTW5ouc+B0eLjD0T5zbdUPmb5NwrkxnzC fiXaTHLC9IPyFA5zFoqErgotAi3RhGJkYfB1pVn6V5dFF79MbXS+emWnYRi8qZyb MEK44o0hanmPPRTYtidbkgOUHAq8Q06AaYZ/jbkLypjne54sc6ifS3kc7/jXba3j JeljH3S+J+gq85IvQQTU0BfbCRVJhFTqz1IPzsdDkNvC+3UI6ax6yup5mpAQ8cw0 TH/BGsH2hVAjEYWEgDWSMnC0jEHsw50a9ok57k/ryOPduxKc53Rvb41yAS4fSPo3 tPhTidMD6tfPdpD5wQJlV7sAFSDDYqGFb11ndlOMZSZsGvJ+5m2qTKNAZxCp/16p YTgtm2zdQB3Ph2OaGk7AOYPVwo7LR9efG7It/ArLiWgbZ2dYfNaNv7mLJ/4yohRl 0mX0PY3Pg6YhrCPiu6HOLQ0PJUY/SZKpUGR2pIUWQJr6hgi6Qpo= =CQr+ -----END PGP SIGNATURE----- --vybvstwjxqtvcrmg--