Hi Jeremy, Thank you for your comments, reply follows inline: Jeremy Stanley <fungi@yuggoth.org> 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): >> >> https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/16 >> >> 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
Attachment:
signature.asc
Description: PGP signature