<div dir="ltr">This all sounds good to me. Find an updated patch attached.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 15, 2017 at 11:35 PM, Niels Thykier <span dir="ltr"><<a href="mailto:niels@thykier.net" target="_blank">niels@thykier.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Michael Stapelberg:<br>
<div><div class="h5">> On Mon, May 15, 2017 at 8:34 PM, Niels Thykier <<a href="mailto:niels@thykier.net">niels@thykier.net</a>> wrote:<br>
><br>
>> Michael Stapelberg:<br>
>>> On Mon, Apr 10, 2017 at 12:55 PM, Niels Thykier <<a href="mailto:niels@thykier.net">niels@thykier.net</a>><br>
>> wrote:<br>
>>><br>
>>>> On Wed, 22 Mar 2017 19:01:54 +0100 Michael Stapelberg<br>
>>>> <<a href="mailto:stapelberg@debian.org">stapelberg@debian.org</a>> wrote:<br>
>>>>> Package: debhelper<br>
>>>>> Version: 10.2.5<br>
>>>>> Severity: normal<br>
>>>>><br>
>>>>> Currently, when trying to build a Debian package whose binary packages<br>
>>>>> specify “€œArchitecture: arm64“€ on an amd64 machine, I get the<br>
>>>> following<br>
>>>>> error message:<br>
>>>>><br>
>>>>> raspi3-firmware $ dh clean<br>
>>>>> dh: No packages to build.<br>
>>>>><br>
>>>>> While this is technically correct, the error message could be way<br>
>>>>> friendlier: I’€™d suggest something along the lines of “No packages to<br>
>>>>> build (architecture mismatch: got amd64, want arm64)“€ .<br>
>>>>><br>
>>>>> What do you think?<br>
>>>>><br>
>>>>> [...]<br>
>>>><br>
>>>> I am fine with getting patches for the better error messages.<br>
>>>><br>
>>><br>
>>> Perfect. Find attached a patch to that effect.<br>
>>><br>
>>><br>
>><br>
>> Thanks,<br>
>><br>
>> I am not sure that it is safe to change the return value of<br>
>> package_arch(). E.g. it is used to determine the name of the binNMU<br>
>> changelog, and I suspect things will break if all binNMUs start to use<br>
>> "changelog.Debian.linux-any.<wbr>gz" regardless architecture. :)<br>
>><br>
><br>
> Thanks for the details. I found 4 callers of package_arch, of which 2<br>
> merely compare whether package_arch returns 'all'.<br>
<br>
</div></div>Inside debhelper itself only or archive-wide? It is a part of<br>
debhelper's API for dh_* tools, so I would rather be safe than sorry.<br>
<span class=""><br>
> I think it would be<br>
> cleaner to move the “turn specified arch into actual build arch†logic into<br>
> the remaining 2 callsites, rather than keep the old misnomer package_arch<br>
> around. Do you agree? If not, what do you suggest we do?<br>
><br>
<br>
</span>I think it was designed to be "give me the concrete architecture value<br>
of this package in this build" (which would either be "all" or<br>
DEB_HOST_ARCH, which buildarch() gives despite its name).<br>
<br>
<br>
I would be happy to have all of the following three functions (with good<br>
names):<br>
<br>
 * is-this-an-arch-all-package<br>
  - would clarify two of the callsites despite being trivial<br>
  - package_is_arch_all ?<br>
 * The function that behaves like packages_arch does now<br>
  - This basically gives you the architecture value that goes into the<br>
   Architecture field of the .deb<br>
  - package_binary_arch<br>
 * The function that behaves like packages_arch as you proposed<br>
  - This basically gives you the value of the Architecture field for<br>
   the binary as it is listed in d/control.<br>
  - package_declared_arch ?<br>
<br>
What is your take on the above functions and good names for them?<br>
<br>
Thanks,<br>
~Niels<br>
<br>
<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Best regards,<br>Michael</div>
</div>