Bug#626775: lintian: should accept "any all" in Architecture in .dsc and not trigger magic-arch-in-arch-list

[Russ Allbery <rra@debian.org>]

Raphaël Hertzog <hertzog@debian.org> writes:

> Next version of dpkg (1.16.1) will keep "all" in the Architecture field
> on .dsc even if there's a binary with architecture "any".

> But when a .dsc contains "Architecture: any all", lintian complains with:
> E: dpkg source: magic-arch-in-arch-list
> N:
> N:   The special architecture value "any" only make sense if it occurs
> N:   alone. The value "all" may appear together with other architectures in
> N:   a *.dsc file but must occur alone if used in a binary package.
> N:   
> N:   Refer to Debian Policy Manual section 5.6.8 (Architecture) for
> N:   details.
> N:   
> N:   Severity: serious, Certainty: certain
> N:

> This error is correct for the fields in debian/control but not for the
> architecture field in the .dsc.

> Please update lintian (I'll file a bug against policy at the same time).

Hi Raphaël,

Policy 5.6.8 specifically says this is not allowed.  So I think the
"cleaner" sequence here would have been:

1. File a bug to request a change to Policy and get consensus on that
   change, waiting for that change to be approved.  (You don't have to
   wait for it to actually get applied, certainly.  That's sometimes slow.
   But at least raising it and getting some seconds.)

2. File a bug asking for Lintian to be updated to reflect the Policy
   change (or just wait for Policy to be released, since we update Lintian
   to match Policy).

3. Then change dpkg.

You certainly have good reasons for these design choices, and I think it's
unlikely anyone is going to object to this one in particular, but these
interfaces are project-wide interfaces and sometimes changes cause
unexpected problems.

I'm probably just reading a bit too much finality into "next version of
dpkg (1.16.1) will keep," but it can be a bit off-putting to get the
feeling that dpkg's source code is authoritative for the meaning of
Policy-standardized fields and the rest of the project is expected to get
in line without any other discussion.  I think it creates some unnecessary
tension that the above order would have defused.

All that said, this seems like a reasonable change to me, and I'll happily
second the Policy bug.

(I suspect that this ordering may be due to slowness in action on Policy
bugs, which I know has been a source of frustration for some of your
work.  If you have a moment to come up with a list of Policy bugs that you
find particularly vexing and would like to get resolved, particularly if
any of them are relatively straightforward, could you send me that list?
I have more time right now to work on Policy than I have in quite a while,
and I promise to take a look.  dpkg-buildflags is already high on my list,
for example.)

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>