Re: Bug#1131015: mention Files-Excluded/Included-* in copyright-format-1.0.xml

Simon Josefsson <[email protected]> Sat, 21 Mar 2026 10:17:28 +0100

Newsgroups	gmane.linux.debian.devel.policy
Message-ID	<[email protected]>

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 (application/pgp-signature, 1.2 KB)