Hi dkg, On Thu, May 16, 2024 at 10:15:52AM -0400, Daniel Kahn Gillmor wrote: > Hi Guido-- > > On Thu 2024-05-16 08:39:27 +0200, Guido Günther wrote: > > Great! This matches my preferred way too. > > ☺ Thanks for walking through the options here with me! > > > Wouldn't d/copyright's `Files-Excluded:` work here too? I'm using that > > for similar purposes as it even allows to use `gbp import-orig --uscan` > > and have things filtered out. `debian/clean` could parse the pattern from > > there. > > Hm, I don't know what the semantics are for Files-Excluded, or what > other side effects they have. The documentation for the > machine-readable copyright format: > > https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ > > doesn't even include the word "Excluded", let alone "Files-Excluded" > (see #685506, sigh). According to > https://wiki.debian.org/UscanEnhancements#Deleting_Files_using_Files-Excluded_field_in_debian.2Fcopyright > the Files-Excluded field actually affects the tarball by causing uscan > to re-pack it without those files. > > Doing the tarball re-packing would mean breaking the upstream tarball's > cryptographic signature, so i'm not sure i want to do that. The goal > here is to increase attributability and provenance, and breaking the > upstream cryptographic signature seems to work against that goal.
But you'd break that when filtering out files? I think what keeps me confused: the tarball uploaded to Debian is the filtered one and hence has a different checksum, no? > > > What if you'd read the filter list in the `clean` target? > > Hm, while i depend on gbp for my regular packaging workflow, one of the > things i like about it is how it wraps itself around other packaging > workflows. If i remove debian/gbp.conf from my package's source, the > source can still build just fine using dpkg-buildpackage or debuild. > I'd like to keep that property. I understand that point. > > > I think what you propose is doing it the other way around: Have gbp > > run `debian/rules clean` to have a programatical way of filtering? > > right, that would do the job, and is probably the more principled way to > do it than merely parsing debian/clean. It would work regardless of It would also have the upside that packages invoking `dh_clean … path1 path2` would still work. Another reason to not parse debian/clean verbatim is that we'd also need to support dh's substitution variables and would forever need to follow what dh does (and we might even need to pay attention to the dh compat level of the package) as otherwise things would break on people. > whether the packaging used debhelper or not. Does that seem like a > plausible way to operate gbp import-orig? That would be an approach. Implementation wise the "tricky" bit is that you don't have debian/ on the upstream branch you want to filter so dh_clean or `debian/rules clean` won't work as is . So we'd need to overlay that (which is certainly doable, just wanted to point it out). So that's a lot of effort for s.th. that can already be done via either gbp.conf or FilesExcluded. I'm not against it, just looking at the pros and cons. Cheers, -- Guido
