Hi Guillem (2024.03.30_04:41:37_+0000) > > 1. Move towards allowing, and then favoring, git-tags over source tarballs > > I assume you mean git archives out of git tags? Otherwise how do you > go from git-tag to a source package in your mind?
There are some issues with transforming upstream's git-centric world into tarballs for Debian source packages, that are worth bearing in mind. The upstream git repository has some extra metadata available that upstream build tools start depending on. Things like: versions, tracked files, and ignored files. This came up in the Python world, where setuptools-scm has become more popular over the years. This is a plugin for setuptools that extracts some metadata from the git repository: 1. Determine the current version. Historically, specified in setup.py. 2. Determine the data files that should be shipped in the installed package. Historically, these were specified in a MANIFEST.in file, but developers got lazy and delegated this problem to git. Currently we set the version for packages that depend on 1 by an environment variable that setuptools-scm will consume. For packages that get file lists from git, it's a little more complex. setuptools writes a foo.eggi-info/SOURCES.txt into source artifacts that it produces (sdists). When this file is present, it's used as a list of files. https://setuptools.pypa.io/en/latest/deprecated/python_eggs.html#sources-txt-source-files-manifest So... for Python packages using setuptools-scm, we're pushed towards depending on upstream-created source tarballs (sdists), rather than upstream git archives, because we don't have the ".git" directory in our source packages. I can imagine that other ecosystems would run into similar problems and solve them by inventing similar protocols, if they solve them at all. Upstreams would probably prefer that we used git repositories *directly* as source artifacts, but that comes with a whole other can of worms... Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
