Hi, On 1/6/26 1:59 AM, Ian Jackson wrote:
Sadly, "well-maintained" by current (legacy) Debian standards does not mean that the .dsc in Debian even corresponds to upstream git, let alone that it is easy to automatically verify that correspondence.
There are also a lot of well-maintained packages where the .orig archive does not correspond to upstream git because of omitted files.
Firstly, it is still common Debian practice to import into git upstream "source tarballs" (which are almost always actually intermediate build products, and often unreproducible). Indeed not importing tarballs is controversial in Debian even though doing so has been obsolete, hazaardous, and bizarre to outsiders, for many years.
A lot of the things Debian has been doing have been bizarre to outsiders. There is a whole anthropology article about the meaning of a keysigning party on a Finnish parking lot as a bonding ritual. That doesn't mean it's wrong.
We also won't be able to stop importing tarballs, because there are projects that *do* release tarballs as artifacts, and sign those.
Another thing that is difficult to handle are upstreams that use submodules -- for example, the upstream for one of my packages uses submodules that themselves refer to other submodules, and some of the links are relative, some are absolute.
I currently repack these into a single tarball, with uscan. Not great, not terrible. I want to switch these over to multiple tarballs, each of them generated using git-archive, so we have multiple commit-id annotations, which should make it easier to track where they are coming from.
For a git server, we can probably bodge something with "url.<base>.insteadOf" git config options here, but my feeling is that we will be playing whack-a-mole with these, it will be more brittle than necessary, and it will make future development a lot harder because the interface just got a lot bigger -- especially the interface that the trusted processing on the server needs to implement, and the interface that we need to describe in Debian Policy.
We will also need to prepare for upstreams to start using sha256 objects. Github's unwillingness to support sha256 is buying us some time for now, but git upstream is working on tools to convert an entire repository and provide lookup of sha1 object IDs -- this will be another tooling challenge for us to handle.
This makes the choice of tarballs less bizarre, I think: they are not a moving target. To use git as an interface for the archive, we also need to make git less of a moving target, and do so in a way that is not restrictive for upstream authors.
I'm also missing a plan how to distribute the source code after the transition is complete. For static files, we have a mirror network, sponsored CDNs and scripts to create CD-ROM images, and I can easily create a local mirror using debmirror if I want.
Replicating a git server is a lot harder, so I expect a lot fewer volunteers to offer space and bandwidth for that in universities, I doubt we can get the big CDN providers on board, and we don't have a plan how to make CD-ROMs either.
This is not a problem as long as we are generating .dsc files still.Without a plan, we will be doing this indefinitely, or until someone decides that it is too painful to continue, and we (and our users) need to accept a few regressions in order to move forward for the sake of modernity, and there will be a massive flamewar about it.
Simon
OpenPGP_signature.asc
Description: OpenPGP digital signature
