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

Re: Debian choice of upstream tarballs for packaging

On Mon, 16 Aug 2021 09:18:34 +0800, Paul Wise wrote:

> I noticed that sometimes Debian's choice of upstream source for
> packaging can be suboptimal. This is especially apparent for the
> different per-language upstream packaging ecosystems[1], where the
> upstream packaging differs from the upstream VCS in some significant
> ways, including missing files, prebuilt files, embedded copies etc.
> While the upstream VCS also sometimes has these issues, it is often
> much less problematic than the upstream packaging ecosystems.
> I'd like to suggest that we standardise on the upstream VCS for our
> orig.tar.gz files and phase out use of upstream packaging ecosystems.
> 1. the ecosystems I'm talking about include cargo, npm, browser
> extensions, rubygems, pypi, CPAN etc.

Sorry for being a bit late to the party; as you mention CPAN here, I
thought I'd share some thoughts about it.
(We briefly discussed the topic at the pkg-perl BoF during DebConf
[0] but this is not an offical team statement.)

I see the advantages of the proposal but I think for the perl
ecosystem it doesn't make a whole lot of sense, for two reasons:

- First, CPAN and Debian are quite similar (for better or worse :));
  not only about the same age but for both projects the canonical
  way of distribution is via tarballs from mirrors - the Debian
  archive and the CPAN mirror network. And for both project there is
  no requirement to use any VCS or even less a specific one or a
  specific hosting for a VCS.
- Second, using only the VCS of a CPAN distribution is not ideal
  because it misses information which is created at release time and
  which we rely on. So taking the code from an upstream repo
  basically means doing part of a release ourselves.

In general, the above mentioned problems of discrepancies between
upstream VCS (if they exist) and upstream tarballs are minor or close
to non-existant in the CPAN world. Hence switching to a VCS-based
approach wouldn't really solve any actual problem in almost all cases
and would create challenges for our tools and workflows.

There are exceptions where we do use the upstream VCS as the tarball
indeed contains undesirable artifacts; and we agreed in the BoF that
improving our tooling to work from a VCS instead of tarballs would be


[0] https://lists.debian.org/debian-perl/2021/08/msg00013.html

 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe

Attachment: signature.asc
Description: Digital Signature

Reply to: