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. > 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 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 whether the packaging used debhelper or not. Does that seem like a plausible way to operate gbp import-orig? --dkg
signature.asc
Description: PGP signature
