Hi Russ, On Wed, 2024-06-19 at 16:06 -0700, Russ Allbery wrote: > I appreciate that you're trying really hard to find a way to represent the > Git tree directly in a source package so that no build step is required > and building the tree of files locally is trivial. I understand that you > truly think that this accomplishes the same goal with some acceptable > lossage around the edges. But it doesn't; it's missing the point. The > point is that there are a wide variety of potential transformations > between the Git tree and the source package required to accomodate the > range of Git workflows used in Debian today *and tomorrow*.
Let us talk about *today*. How many packages would not be possible to upload via tag2upload if one required a signature covering content of packages? Is it 0.1%? Is it 90%? For *tomorrow* we might change things in the future. Some things like arbitrary code execution at .dsc construction time are fairly useful after all (required for some workflows, even when it might not change the files ending in the source package). Pretty much all changes in Debian (say systemd, usrmerge, ...) happened incrementally. Why should that not be appropriate here? (Or was a slow move wrong in retrospect and we should have decided to support only systemd and drop sysvinit in 2014, and to move to only usrmerge also several releases earlier?) > Having a > source package build system in the middle is what allows us to *decouple* > the workflow from the build output so that people can use the workflow > that works best for them and we get standardized Debian source packages > out the other end. Why should there be a standardized Debian source package in the end (where tag2upload might try to build quilt patches) when nobody but a machine is supposed to use them? Also, if they are standardized why are there options for the maintainer to control how the source package gets constructed? (Like an option to control how many patches end up in d/patches.) > But the number of workflows > that can be supported under that restriction is extremely limited without > making the uploader build the source package locally, still. It might be > useful for some relatively simple cases, but it doesn't move the source > package build step to a Debian project infrastructure system and it still > requires that the uploader build the source package file tree locally. The number of workflows that can be supported without arbitrary code execution at source package construction time is also extremely limited. As asked earlier: it would be helpful to know how many packages would be affected by this. Ansgar
