Hi! On Wed, 2024-05-22 at 03:02:50 -0400, Daniel Richard G. wrote: > I've rebased this patch against current Git.
Thanks for the patch, and sorry for not commenting earlier. As I mentioned elsewhere, I've had this in mind, but I guess drafted multiple replies in my head which ended up never being delivered. (Also source package formats have become something of a contentious topic, and it feels sometimes a bit demotivating to work on these.) > To recap, this option enables (re)building a source package without cross- > checking against the orig tarball, in scenarios where the latter is > superfluous and expensive. Some benchmarks from a package I work with > basically tell the story. This is with my patch applied: Is this superfluous because you don't need the source at all (in which case I think a better option might be to not generate it) or because you (or the tool driving dpkg-buildpackage or dpkg-source) knows that there have been no changes (for example the source-tree being in a VCS)? Or perhaps this is needed for example for a CI or build system to transport the source-tree across installations, then perhaps a different transient format could be used for that purpose only (for example «dpkg-source --format="3.0 (git)" -b dir»? For the patch itself, I'm not very fond of the semantics it introduces, because while something similar can probably be specified for format 1.0, that one has rather loose semantics and is more prone to error. Personally I don't trust myself to remember if I've done changes to a tree (if it's not tracked by a VCS), so I see this diluting its robustness and checks. Depending on the scenarios you have in mind, a better option might perhaps be to either make dpkg-source integrate more tightly with a VCS, or perhaps create a new source format. Both of which I've had in mind for a while, but see the motivation bit above. For the VCS integration, something I've been pondering (and started drafting on a git branch) is a new extraction mode where dpkg-source would for example unpack the orig tarball(s) from a "3.0 (quilt)" source package, and create a git repo out of those, while tracking the digests for those tarballs. Then import the patches into git commits (and remove them from debian/patches/). The problem is that I don't really want to have to massage or track patch format differences to make them valid git commits, like some tools do. Then the build process could regenerate the "3.0 (quilt)" out from that working directory. And this could give you the speed you need, while not losing on robustness I guess? Perhaps a solution to the guarantee of having patches that are always git commits, could be to add a format variant from the quilt one where that holds (say "3.0 (git-format-patch)" or whatever), which would make that trivial then, although harder to deploy. Or maybe just keep "3.0 (quilt)" but add a file marker under debian/source/ or an option under debian/source/options. The other option could be to create a new git-based source format, my thinking has been on something resembling the current "3.0 (git)" format but shallow with a single commit for the upstream part, and a packaging branch with the packaging bits and the patches against upstream. This could be useful for git snapshots, or upstreams that do not release tarballs. And could give you the speed you look for too I guess? For the latter it could be interesting to get other parties that have been working on source and VCS handling, although my concern is that at this point the various groups appear to have very strong views on how this should look like, and I think there might even be disagreement on fundamental base topics. But I'd still like to think these are not insurmountable, but perhaps this would require an in-person gathering to be effective at all, which is limiting. Thanks, Guillem
