[debhelper-devel] Bug#858467: Bug#858467: Please expand on error message "No packages to build." when architectures do not match

Michael Stapelberg stapelberg at debian.org
Wed May 17 06:35:51 UTC 2017


This all sounds good to me. Find an updated patch attached.

On Mon, May 15, 2017 at 11:35 PM, Niels Thykier <niels at thykier.net> wrote:

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


-- 
Best regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debhelper-devel/attachments/20170517/4cbc0b21/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-include-present-wanted-architecture-in-error-message.patch
Type: text/x-patch
Size: 5710 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/debhelper-devel/attachments/20170517/4cbc0b21/attachment-0002.bin>


More information about the debhelper-devel mailing list