XPost: linux.debian.devel, linux.debian.policy   
   From: cjwatson@debian.org   
      
   On Wed, Feb 11, 2026 at 08:52:04PM +0100, Simon Josefsson wrote:   
   >The Python Team's Policy insistance on use of pristine-tar and throwing   
   >away upstream git history is [1]:   
   >   
   >   DPT requires a pristine-tar branch, and only upstream tarballs can be   
   >   used to advance the upstream branch. Complete upstream Git history   
   >   should be avoided in the upstream branch.   
      
   Well, for my own packages I insist on including upstream git history, so   
   this certainly wasn't my choice, and it was before my time on the DPT.   
   However, I suspect that it was a pragmatic choice to make it even   
   slightly practical to maintain several thousand source packages in a   
   more or less uniform structure despite the upstreams using a pretty wide   
   variety of code hosting mechanisms and practices.  IIRC there are still   
   quite a few packages that use something other than git or that have no   
   public git repository, and there are definitely plenty where the   
   upstream maintainer seems to pay more attention to what's on PyPI than   
   what they've tagged in git (e.g. they don't bother to push tags).  The   
   big popular packages usually work the way you'd expect, but there is a   
   significant long tail.   
      
   We already have an almost impossible amount of work to do just keeping   
   up with ecosystem-wide changes (sure, there's been nothing even remotely   
   on the scale of the Python 3 transition for a long time, but small   
   probabilities of being affected by any given breaking change multiplied   
   by thousands of packages still mount up quickly).  Despite understanding   
   the downsides of the current team policy, I for one have absolutely no   
   appetite or capacity for yet another thing that requires us to go around   
   and reorganize everything.  dgit/tag2upload doesn't require us to do   
   that; it can slot into our existing workflows, and not all team members   
   even have to agree.   
      
   >The pypi.debian.net man-in-the-middle upstream tarball redirector is the   
   >recommended (?) debian/watch URL to use for Python packages [2].   
      
   We've been gradually moving away from this in some cases in favour of   
   pointing to forge-generated tarballs, but it varies somewhat.  There is   
   no one approach that works for all Python packages:   
      
     * Source distributions ("sdists") pushed to PyPI are technically a   
       build product of the upstream source tree, and sometimes they don't   
       include all the files we need - for example, omitting tests is fairly   
       common, as is trying to include tests but omitting some of the data   
       files they need.  And some upstreams only publish wheels to PyPI and   
       not sdists.   
      
     * On the other hand, it's also fairly common to run into packages where   
       upstream uses something like submodules, and so the forge-generated   
       tarballs will be incomplete and basically useless.  So will pointing   
       directly to upstream git tags unless you mess about with multiple   
       components.  In those cases the sdists on PyPI usually work fine and   
       are much less hassle.   
      
   So sure, the situation is not ideal.  But it might be worth walking a   
   mile in our shoes first.   
      
   --   
   Colin Watson (he/him)                              [cjwatson@debian.org]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)