Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.maint.python > #13439

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

Path csiph.com!aioe.org!bofh.it!news.nic.it!robomod
From Simon McVittie <smcv@debian.org>
Newsgroups linux.debian.maint.python
Subject Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided upstream source tarballs
Date Sat, 26 Jun 2021 00:10:01 +0200
Message-ID <Cu2bn-5Gx-1@gated-at.bofh.it> (permalink)
References <Cu0VX-4MG-5@gated-at.bofh.it>
X-Mailbox-Line From debian-python-request@lists.debian.org Fri Jun 25 22:07:08 2021
Old-Return-Path <smcv@debian.org>
X-Amavis-Spam-Status No, score=-9.873 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, DKIMWL_WL_HIGH=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, LDO_WHITELIST=-5, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
MIME-Version 1.0
Content-Type text/plain; charset=utf-8
Content-Disposition inline
Content-Transfer-Encoding 8bit
X-Mailing-List <debian-python@lists.debian.org> archive/latest/19229
List-ID <debian-python.lists.debian.org>
List-URL <https://lists.debian.org/debian-python/>
List-Archive https://lists.debian.org/msgid-search/YNZTePg8XtN9Tf8T@momentum.pseudorandom.co.uk
Approved robomod@news.nic.it
Lines 52
Organization linux.* mail to news gateway
Sender robomod@news.nic.it
X-Original-Date Fri, 25 Jun 2021 23:06:48 +0100
X-Original-Message-ID <YNZTePg8XtN9Tf8T@momentum.pseudorandom.co.uk>
X-Original-References <877dihvfp9.fsf@DigitalMercury.dynalias.net>
Xref csiph.com linux.debian.maint.python:13439

Show key headers only | View raw


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

    — https://www.debian.org/doc/manuals/developers-reference/best-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'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 hosting
platform.

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.

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).

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 :-)

    smcv

Back to linux.debian.maint.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC] DPT Policy: Canonise recommendation against PyPi-provided  upstream source tarballs Nicholas D Steeves <sten@debian.org> - 2021-06-25 22:50 +0200
  Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided  upstream source tarballs Jeremy Stanley <fungi@yuggoth.org> - 2021-06-25 23:20 +0200
    Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided  upstream source tarballs Scott Talbert <swt@techie.net> - 2021-06-25 23:40 +0200
      Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided  upstream source tarballs Nicholas D Steeves <sten@debian.org> - 2021-06-26 00:50 +0200
    Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided  upstream source tarballs Nicholas D Steeves <sten@debian.org> - 2021-06-26 00:30 +0200
      Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided  upstream source tarballs Jeremy Stanley <fungi@yuggoth.org> - 2021-06-26 01:50 +0200
        Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided  upstream source tarballs Nicholas D Steeves <sten@debian.org> - 2021-06-26 02:10 +0200
        Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided  upstream source tarballs Paul Wise <pabs@debian.org> - 2021-06-26 04:10 +0200
          Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided  upstream source tarballs Jeremy Stanley <fungi@yuggoth.org> - 2021-06-26 06:20 +0200
          Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided  upstream source tarballs Martin <debacle@debian.org> - 2021-06-26 11:30 +0200
      Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided  upstream source tarballs Simon McVittie <smcv@debian.org> - 2021-06-26 12:20 +0200
    Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided  upstream source tarballs Paul Wise <pabs@debian.org> - 2021-06-26 04:00 +0200
  Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided  upstream source tarballs Simon McVittie <smcv@debian.org> - 2021-06-26 00:10 +0200
    Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided  upstream source tarballs Nicholas D Steeves <sten@debian.org> - 2021-06-26 01:10 +0200
      Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided  upstream source tarballs Jeremy Stanley <fungi@yuggoth.org> - 2021-06-26 02:00 +0200
      Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided  upstream source tarballs Brian Thompson <brian@hashvault.io> - 2021-06-26 05:50 +0200
        Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided upstream source tarballs Donald Stufft <donald@stufft.io> - 2021-06-26 06:30 +0200
  Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided  upstream source tarballs Paul Wise <pabs@debian.org> - 2021-06-26 04:00 +0200
  Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided  upstream source tarballs Louis-Philippe Véronneau <pollo@debian.org> - 2021-06-27 01:00 +0200
    Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided  upstream source tarballs Jeremy Stanley <fungi@yuggoth.org> - 2021-06-27 02:20 +0200
    Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided  upstream source tarballs Emmanuel Arias <eamanu@yaerobi.com> - 2021-06-28 04:50 +0200
      Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided  upstream source tarballs Jeremy Stanley <fungi@yuggoth.org> - 2021-06-28 18:30 +0200

csiph-web