Christian Kastner <[email protected]> writes: > On 2026-03-17 15:00, Simon Josefsson wrote: >> The corner-case I'm thinking of something like this: >> >> Files-Excluded: foo/* >> Files-Included: foo/bar* > > At the risk of side-tracking this, I'd like to point to #1106232l, where > mk-origtargz currently, IMO, appears to apply Files-Included too broadly. > > Given: > > Files-Excluded: foo/* /baz* > Files-Included: foo/bar* > > The Files-Included would also include a /baz/foo/bar, should it exist, > even though /baz* is excluded.
The document has this to say about Files: Patterns match pathnames that start at the root of the source tree. Thus, “Makefile.in” matches only the file at the root of the tree, but “*/Makefile.in” matches at any depth. Thus if we want this to be consistent, I think the tools should behave like that for Files-Excluded/Included* too. Finally, I'm sure there are bugs in all sorts of tools and existing debian/* files, but bugs should not block a specification for things. It means we have to be more careful to describe the "intended" semantics properly, though, whatever it may be, so the tools can reasonably be aligned with the specification eventually. Even better of the tool maintainers agree with the intended semantics (even if the tools remain buggy until fixed). /Simon > (This doesn't look like much of a problem in the example above, but > substitute foo|bar|baz with more common patterns, like 'src' and 'c.*') > > So one would need to consider the Policy's stance on this: should the > current (IMO buggy) behaviour be confirmed as Policy, or would the > Policy mandate a change of this. > > It's entirely possible that this is by design, hence all the IMOs. > > Best, > Christian > >
signature.asc
Description: PGP signature
