Path: csiph.com!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!bofh.it!news.nic.it!robomod From: Nicholas D Steeves Newsgroups: linux.debian.maint.python Subject: Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided upstream source tarballs Date: Sat, 26 Jun 2021 01:10:01 +0200 Message-ID: References: X-Mailbox-Line: From debian-python-request@lists.debian.org Fri Jun 25 23:02:03 2021 Old-Return-Path: X-Amavis-Spam-Status: No, score=-11.499 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, FOURLA=0.1, KHOP_HELO_FCRDNS=0.399, LDO_WHITELIST=-5, PGPSIGNATURE=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001] autolearn=ham autolearn_force=no X-Policyd-Weight: using cached result; rate: -3.5 X-Rg-Cm: Clean X-Originating-IP: [65.94.67.236] X-Rg-Env-Sender: nick.steeves@bell.net X-Rg-Rigid: 60C89459007C32B8 X-Cm-Envelope: MS4xfDmRKsJWr0uBnWptg4x5JwF+KiX2HYyCoY92HFNYi9h/e5QJJ0MLONexdfsuLfN4lPfl6cksVH8jr9iQk6EA01gF3RpDwU8eeVQaqhURwBFUkT++9E+S BIa/hlZmK7lk3BQ7B6Wos8xQc/2d3KuL5dSiXC2clvT5lxmQH3XoVOpSmVzIXsdu7XRkmCzux+MZ5WV8ysKfsjYkG2Gd04A/n3ECJNgVy0nVkuLlZ+uT6Iqt vkEOvKD/8Q75VqH91JUHD08weWyJqzuR1TAqmvUBxZ0e8w6O3uIsbvI6HT3XLi4s1fGHcO2r36dE+wRI/UfCoDAzC+Ce0/xZ3l3flbiYSoAMwHfzfLBVb7Ml NbhFq0MO X-Cm-Analysis: v=2.4 cv=ENdlb3VC c=1 sm=1 tr=0 ts=60d66057 a=MAO/b3cUwoQHNHibRY5CTw==:117 a=MAO/b3cUwoQHNHibRY5CTw==:17 a=r6YtysWOX24A:10 a=xNf9USuDAAAA:8 a=eW2YrdGUJunjvbv3pgcA:9 a=QEXdDO2ut3YA:10 a=GkSHvS3Q8RcA:10 a=uL31O8nKrJEA:10 a=GAMVMMoa8jnMmJ-6Nk0A:9 a=FfaGCDsud1wA:10 a=SEwjQc04WA-l_NiBhQ7s:22 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Mailing-List: archive/latest/19232 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/871r8pczvw.fsf@DigitalMercury.dynalias.net Approved: robomod@news.nic.it Lines: 127 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Fri, 25 Jun 2021 19:01:39 -0400 X-Original-Message-ID: <871r8pczvw.fsf@DigitalMercury.dynalias.net> X-Original-References: <877dihvfp9.fsf@DigitalMercury.dynalias.net> Xref: csiph.com linux.debian.maint.python:13442 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Simon, Simon McVittie writes: > On Fri, 25 Jun 2021 at 16:42:42 -0400, Nicholas D Steeves wrote: >> I feel like there is probably consensus against the use of PyPi-provided >> upstream source tarballs in preference for what will usually be a GitHub >> release tarball > > This is not really consistent with what devref says: > > The defining characteristic of a pristine source tarball is that the > .orig.tar.{gz,bz2,xz} file is byte-for-byte identical to a tarball > officially distributed by the upstream author > > =E2=80=94 https://www.debian.org/doc/manuals/developers-reference/bes= t-pkging-practices.en.html#best-practices-for-orig-tar-gz-bz2-xz-files > > Sites like Github and Gitlab that generate tarballs from git contents > don't (can't?) guarantee that the exported tarball will never change - I agree 100% > I'm fairly sure `git archive` doesn't try to make that guarantee - so it > seems hard to say that the official source code release artifact is always > the one that appears as a side-effect of the upstream project's git hosti= ng > platform. > Also agreed 100%. This line of inquiry is actually why I think using upstream tags is best, but even then it's possible upstream will delete the tag and push a new one. Does PyPi provide immutable releases? If so, yes, I agree there's a strong argument to be made for using PyPi vis =C3=A0 vis DevRef within a DPT context where upstream git tags (and history) are not merged :-) > That doesn't *necessarily* mean that the equivalent of a `git archive` > is always the wrong thing (and indeed there are a lot of packages where > it's the only reasonably easily-obtained thing that is suitable for our > requirememnts), but I don't think it's as simple or clear-cut as you > are implying. > Also agreed 100%, but I've learned people often look at comprehensive proposals as tldr, so I wanted to try a discussion-based approach ;-) > devref also says: > > A repackaged .orig.tar.{gz,bz2,xz} ... should, except where impossible > for legal reasons, preserve the entire building and portablility > infrastructure provided by the upstream author. For example, it is > not a sufficient reason for omitting a file that it is used only > when building on MS-DOS. Similarly, a Makefile provided by upstream > should not be omitted even if the first thing your debian/rules does > is to overwrite it by running a configure script. > > I think devref goes too far on this - for projects where the official > upstream release artifact contains a significant amount of content we > don't want (convenience copies, portability glue, generated files, etc.), > checking the legal status of everything can end up being more work than > the actual packaging, and that's work that isn't improving the quality of > our operating system (which is, after all, the point). > I agree, and will support a proposal to modify DefRef to this end, because as far as I know the source tarballs in our archive aren't part of a secondary project to archive upstream tarballs as-released (eg: a kind of "ark" or source-bank, like a seed-bank, for DFSG software)...but maybe that is a secondary objective? > However, PyPI sdist archives are (at least in some cases) upstream's > official source code release artifact, so I think a blanket recommendation > that we ignore them probably goes too far in the other direction. > > I'd prefer to mention both options and have "use your best judgement, > like you have to do for every other aspect of the packaging" as a > recommendation :-) > So far the text I've been able to come up with to address this is something like: In some cases PyPI sdist archives may be the most appropriate upstream source tarball (then your "use your best judgement..." as a conclusion) :-) It would be really nice to include technical reasons that describe cases where PyPI is more appropriate, but I don't know any. My experience in Debian thus far has been that "what most closely fulfils Debian ideals" is always preferable to upstream preference. Yes, that's arguably insular, but I thought there was consensus on this. And yes, I agree moderate is better, but I must sadly confess ignorance to the technical reasons why PyPI is sometimes more appropriate. Without technical reasons it seems like a case of ideological compromise (based on the standards I've been mentored to and the feedback I've received over the years). Thanks! Nicholas --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJEBAEBCgAuFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmDWYFMQHHN0ZW5AZGVi aWFuLm9yZwAKCRBaiDBHX30QYTsgEAC133vBploCgIio4s+/vSpT+mhxUjt0lGXt zpRuzrB852yfFcMGZzwgoluiA4CEThh5Cczit8eYSIMm8xWW+8i/l4a5HlbcWFhk TGyVtWNm1YQhUPKWA8dvgQJP/7+d7ozPvAeZXEPfQy2XGEwx349QGZPD0Dph263v 0Pz+Uk0o2poVDSxebvAl8scVjbVlBgIystCSm2IqKcZ6jOLkkiXF1S6G7l2Rr8mu /VqJixlUf8JGpMwr/6mpDmq+I581T9iGf8rU6qfW9hMC5NV1OWECs+RJqZCsQdfH 3FIguvjqC9zl8ZeXPvDMAGNsbIJChK0oW5fFlcR3XjcV7e3g8OwQAL4ZTJ2H2Xy9 WDKUIp81+FOKpSWu/vnxMo7r1mULvnFu7Kw69J4SAh9eWgq+BqKXoMGCugJl8NnY ivYLXR933hnsSYeTDSza8MMzAQjJleB2aR6Ox+V2MVOzkdcXb3FAIl/B3C62+s9Q zJWL+Sjwtp8RK4gQPcCQP8mYFsfuXaMAP5+ptoYzW1/Kx4SDujfbnxJEXxNE1Ghy a1B9rBYIKgDK8tsg4128LrA54dOJBTsyhL89/6wrRRR/vZkCeeFFYdJLVuGNnxeb Mdc8BkGkdW0GKeMMaRXqa/rvn8DB8XnHH6wNtyD+ydr8FjrcU0SWdoZKsL2/Kn9w 6LHEZm7gXg== =0jqR -----END PGP SIGNATURE----- --=-=-=--