[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided upstream source tarballs

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

> "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

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.


Attachment: signature.asc
Description: PGP signature

Reply to: