Bug#1131015: mention Files-Excluded/Included-* in copyright-format-1.0.xml
Simon Josefsson <[email protected]> Sat, 21 Mar 2026 14:03:49 +0100
| Newsgroups | gmane.linux.debian.devel.policy |
|---|---|
| Message-ID | <0e05205c96150e843a66ecd0e3b09eec0f017881.camel__1718.96372209943$1774098342$gmane$org@josefsson.org> |
lör 2026-03-21 klockan 12:52 +0000 skrev Sean Whitton: > Simon Josefsson <[email protected]> [21/Mar 10:01am +01] wrote: > > The rendered text reads like this: > > > > 6.7. Files-Excluded, Files-Excluded-*, Files-Included, Files- > > Included-* > > > > Whitespace-separated list: filename patterns (same as the Files > > field, including the wildcards) used to signal repacking of the > > upstream source source to remove unwanted files. Files-Excluded > > is a > > list of filename patterns matching files (including directories) > > to > > exclude. Files-Excluded-COMPONENT behave the same, but is > > applied to > > a particular orig.tar component only (replacing COMPONENT with > > the > > component name), for multi-orig.tar sources. Files-Included is > > used > > to include some files (or directories) that were excluded by a > > Files-Excluded expression. Files-Included-COMPONENT is > > similarily > > used to re-include paths excluded by Files-Excluded-COMPONENT. > > These > > fields are supported by uscan and mk-origtargz. > > > > I believe this is a self-contained specification, and does not need > > any > > external references in order to understand, based on already widely > > implemented properties. Thus addressing Sean's concern about the > > syntax > > of these fields being experimental. > > Thanks, this looks good to me as a piece of Policy. I'm not > qualified > to review its factual accuracy though so it would be great if someone > else could do that. Indeed, and there is no hurry, so I think it would be great to hear feedback from people familiar with implementations of these headers to have better confidence in the text. /Simon
signature.asc
(application/pgp-signature, 1.2 KB)
-----BEGIN PGP SIGNATURE----- iQNoBAAWCgMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmm+lzUUHHNpbW9uQGpv c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA /iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx +3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0 +MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE 8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6 qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFos+eAP9hKWYUfU8U tqMhpZ0Sy4dKFhgEr+Tn7+YNv9lm/sCPAQEAqbW6fWR4785hYgBNdFtZmwcUex5J 45Myaz+cKC207w0= =O+A6 -----END PGP SIGNATURE-----