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
Description: This is a digitally signed message part
