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 00:30:02 +0200 Message-ID: References: X-Mailbox-Line: From debian-python-request@lists.debian.org Fri Jun 25 22:29:43 2021 Old-Return-Path: X-Amavis-Spam-Status: No, score=-11.299 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, FOURLA=0.1, KHOP_HELO_FCRDNS=0.399, LDO_WHITELIST=-5, MURPHY_DRUGS_REL6=0.2, 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: 60C89459007BEDD1 X-Cm-Envelope: MS4xfHRpGy4akPfuJ6aw3thDq7Vc/vhnR8Mc4De1b8yUH9k+mnZkCCdxkXPhs+acqKbcUX3+Uwo4S3bH/Sow9m0qK/T1v90zTZUsegpAomH8NkwJcqdm8Yvg g+ibdFTcDA2WQgXrW037Es3knixs+8D0XrAwExr+luXwPsoPxEaUsrDGeLNl8vzmITk/MMAsOTNpRFiCDrKglWtHUp1qSLTyBVmzxeOzYEEQhh9XKEReun99 jfphclUfxNr8PCiWw71bGJQGa5VDC8LPnmc/12JrZ/LF9slsROQtBgG60NHnzdNSaqoILThP4HfUIXlyS0KH9AMvzzsnagHN+sRLTGuSwhwFsK6Q2iaTKIun pTHc3/dK X-Cm-Analysis: v=2.4 cv=ENdlb3VC c=1 sm=1 tr=0 ts=60d658c3 a=MAO/b3cUwoQHNHibRY5CTw==:117 a=MAO/b3cUwoQHNHibRY5CTw==:17 a=r6YtysWOX24A:10 a=GNVogxh2AAAA:8 a=xNf9USuDAAAA:8 a=fWI3XnKUTaQh3LBNAUQA:9 a=IkVWpnB_AfQA:10 a=CReLcqujrNCFxz1O24oA:9 a=FfaGCDsud1wA:10 a=979E8_6qzvx70RLmGL-T:22 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/19230 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/877dihd1ds.fsf@DigitalMercury.dynalias.net Approved: robomod@news.nic.it Lines: 100 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Fri, 25 Jun 2021 18:29:19 -0400 X-Original-Message-ID: <877dihd1ds.fsf@DigitalMercury.dynalias.net> X-Original-References: <877dihvfp9.fsf@DigitalMercury.dynalias.net> <20210625211721.eluslf3hee5eug7r@yuggoth.org> Xref: csiph.com linux.debian.maint.python:13440 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi Jeremy, Thank you for your comments, reply follows inline: Jeremy Stanley writes: > On 2021-06-25 16:42:42 -0400 (-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, so I made an MR to this effect (moderate recommendation >> rather than a "must" directive): >>=20 >> https://salsa.debian.org/python-team/tools/python-modules/-/merge_requ= ests/16 >>=20 >> Comments, corrections, requests for additional information, and >> objections welcome :-) I'm also curious if there isn't consensus by >> this point and if it requires further discussion > > I work on a vast ecosystem of Python-based projects which consider > the sdist tarballs they upload to PyPI to be their official release > tarballs, because they encode information otherwise only available > in revision control metadata (version information, change history, > copyright holders). The proposal is somewhat akin to saying that a > tarball created via `make dist` is unsuitable for packaging. > A recommendation is non-binding, and the intent of this proposal is to say that the most "sourceful" form of source is the *most* suitable for Debian packages. The inverse of this is that `make dist` is less suitable for Debian packages. Neither formulation of this premise applies to a scope outside of Debian. In other words, just because a particular form of source packaging and distribution is not considered ideal in Debian does not in any comment on its suitability for other purposes. Would you prefer to see a note like "PyPi is a good thing for the Python ecosystem, but sdists are not the preferred form of Debian source tarballs"? It's also worth mentioning that upstream's "official release" preference is not necessarily relevant to a Debian context. Take for example the case where upstream exclusively supports a Flatpak and/or Snap package... > "GitHub tarballs" (aside from striking me as a blatant endorsement > of a wholly non-free software platform) lack this metadata, being > only a copy of the file contents from source control while missing > other relevant context Git would normally provide. "GitHub [and Gitlab!] tarballs" are fairly well understood, and it takes fewer words to talk about them than to write about integrating a merging or rebasing tag-based workflow (possibly with excluded files with a merge driver) in a team that has standardised on git-buildpackage. I might have out-of-date info, btw. Would it still upset the DSA if DPT packages' watch files polled using the lightweight git driver? I also prefer to have upstream git history :-) Thinking about an ideal solution, and the interesting PBR case, I remember that gbp is supposed to be able to associate gbp tags with upstream commits (or possibly tags), so maybe it's also possible to do this: 1. When gbp import-orig finds a new release 2. Fetch upstream remote as well 3. Run PBR against the upstream release tag 4. Stage this[ese] file[s] 5. Either append them to the upstream tarball before committing to the pristine-tar branch, or generate the upstream tarball from the upstream branch (intent being that the upstream branch's HEAD should be identical to the contents of that tarball) 6. Gbp creates upstream/x.y tag 7. Gbp merges to Debian packaging branch. Cheers, Nicholas --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJEBAEBCgAuFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmDWWL8QHHN0ZW5AZGVi aWFuLm9yZwAKCRBaiDBHX30QYcEsEADQbqGg3v9uEd2IEhW4hks/veDiXFuXf4mT g9hATM3Aq90Y7f65+Yxl7lAJVsi6AIt3nHgsxOe6tfIlrRpAk5M/+yhOtGK2TUmS 2phbfUk9QV3w6hpwX5ML/NA0wYUgh1nZD5ByJbNLnn4XOu6Yi+a8Ia+DTX19evz7 Jn/LGkrjjURPB4rTlWp9nHgENycSnpmknXEfjjUU/Sxgv98wTBeT2WzsJEp6Vtkp dkTirf02CMh9BwM7gGLZ+1t8XljKisnaBhlN2va86Qhg/POY5Q3Jf2xbGlC3lT0m VFBuMuE+dKyrcJXekndBoWLOAvITVkbG3xdVBvp/4x+h5svLuaHeVPTw8aySLLDs /wDOMuSB9XWM+GZZzpOO8QEjjr9eXP9elL2lZodnH2JHFuZlWx8UfkqGYfRIxTC2 Gi241k/OqsfCU+COx691Xww+2aeoBhcPXYl2PlSXBP4G1wypdHIFvODcUr/nuEFh 5VDyvAlTlFRbaPLdiTDpdPA0A5kB3S1tARpXBHwm5P4b4miFih60EyNQnwSpdv9Y 9xy5UBpWT0AkrrZ6l5pGXWpHqwtLHyX1Waa6jlXzXq66BgEh9ll+lIo3n4ceY8fW V70lRKldYVYq/qWj5SSWJdf2Ck7RtEI6CT8NtmE0azUalPedJyxdGDU57B1Zjare SPhjpVuR3A== =o8bt -----END PGP SIGNATURE----- --=-=-=--