[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The :native qualifier for cross building

[ replying on-list as suggested by Johannes, please CC me as I'm not subscribed ]

Hi Johannes,

Thanks for your very clear explanation.

I think it would be marvellous if, when test-crossbuild-package-arm64
fails, it would point people towards finding an explanation like this.

I've not really had to worry about cross-building in Debian before, so
while I'm sure that the same information about the distinction between
Architecture and Multi-Arch was present in what is already available,
and I did read what I could find (more than once), this is the first
explanation that allowed me to get some sort of grip on why both need to
exist, and in particular what I was supposed to do to fix the problem in

Johannes Schauer Marin Rodrigues <josch@debian.org> writes:

> Hi Phil,
> Quoting Philip Hands (2022-09-18 22:18:30)
>> Johannes Schauer Marin Rodrigues <josch@debian.org> writes:
>> > Nilesh Patra told us on the #debian-bootstrap channel that you asked on the
>> > #salsaci channel about advice for cross building src:localechooser. Nilesh
>> > mentioned that you wanted to know whether it's correct to just annotate
>> > build dependencies with :native to make it work. Since this practice is
>> > wrong in many cases, maybe we can work together in improving the cross
>> > building documentation so that it will become easier for other maintainers
>> > to fix their cross building problems in the right way? In the hope that it
>> > helps a bit I just added this section to our cross wiki page:
>> >
>> > https://wiki.debian.org/CrossBuildPackagingGuidelines#Avoid_the_.27:native.27_qualifier_if_possible
>> >
>> > If you have any questions, do not hesitate to send all your cross troubles to
>> > our mailing list at debian-cross@lists.debian.org
>> Thanks for asking.
>> I admit that I find the situation a little befuddling.
>> If you look at this job:
>>   https://salsa.debian.org/installer-team/localechooser/-/jobs/3172786
>> you see that it complains:
>>    builddeps:.:arm64 : Depends: locales:arm64 but it is not installable
>>                        Depends: intltool-debian:arm64 but it is not installable
>> Looking at the debian/control for intltool-debian
>> (https://salsa.debian.org/debian/intltool-debian/-/blob/master/debian/control),
>> one sees:
>>   Architecture: all
>> which suggests to me that, if the package is available for any
>> architecture, it really ought to exist for all of them, so it's
>> confusing that it is apparently unavailable on arm64.
> It helped me to think about Architecture:all as a way to help save some mirror
> space as well as some CPU cycles when building packages. We mark a binary
> package as Architecture:all if its contents are the same no matter what
> architecture we want to install the package on. Consider a binary package
> containing a single shell script called /usr/bin/unamesh with the following
> contents:
>     #!/bin/sh
>     uname -a
> Any maintainer would mark such a package as Architecture:all because it only
> contains a single shell script which is obviously identical no matter for which
> architecture the package is built.
> But the contents of the Multi-Arch field has nothing to do with whether the
> contents of a binary package differ between architectures or not. In
> particular, Multi-Arch:foreign tells the dependency resolver, that the
> interface of the package does not differ depending on which architecture it is
> installed. This is not the case for our script. Its behaviour will be different
> depending on the native architecture of the system it is installed on even
> though the package contents are exactly identical. So this binary package
> cannot be marked Multi-Arch:foreign.
> Some real-world examples for Architecture:all packages that cannot be marked
> Multi-Arch:foreign are:
>  - haskell-devscripts #769377
>  - dh-ocaml #769379
>> Is it simply that intltool-debian should also have:   Multi-Arch: foreign
>> (likewise for locales)
>> If so, is there any reason one could possibly object to having that
>> added to such packages?
> In case of locales: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669188
> In case of intltool-debian: https://tracker.debian.org/pkg/intltool-debian
> (click on "Multiarch hinter reports 1 issue(s)")
>> or is it pretty much always the right thing to do?
> No, not at all. Sometimes, an Architecture:all package just contains a shell
> script that does nothing architecture-specific and in that case it can just be
> marked Multi-Arch:foreign. But sometimes there are very subtle interactions of
> the package with the native architecture that make it impossible to mark it as
> Multi-Arch:foreign. Sometimes, it's only the dependencies of a package that
> make it impossible to mark it Multi-Arch:foreign (like python3-mako ->
> python3-markupsafe). One must also note, that whether a package can be marked
> Multi-Arch:foreign depends on what its maintainer declares its interface. There
> exist packages, that do something architecture-dependent but if that thing is
> not considered an interface of this package that other packages are supposed to
> use, then the package can still be marked Multi-Arch:foreign. In the end it's
> probably the package maintainer who can best make this decision. My favourite
> example is "make" which is usually used as a Makefile script interpreter
> without any architecture-dependent behaviour. But consider the following
> Makefile:
> all: -lc
> 	@echo $(<)
> On i386 this will print /usr/lib/i386-linux-gnu/libc.so and on amd64 the same
> Makefile will print /usr/lib/x86_64-linux-gnu/libc.so. Additionally, make is
> able to load shared libraries at runtime:
> https://www.gnu.org/software/make/manual/html_node/Loaded-Object-Example.html
> As a result, make can only be Multi-Arch:allowed and its up to the package
> depending on it to declare whether they want the build architecture or the host
> architecture version.
> If you want to go down this rabbit hole, then there is
> https://lists.debian.org/20121206080512.GL4151@p12n.org
> So, coming back to your original problem, intltool-debian probably should be
> marked as M-A:foreign which will solve your problem. The locales package cannot
> and the right thing to do depends on what the locales package is used for when
> building localechooser?

It looks like the only use of locales in the localechooser udeb is to
get at the file `/usr/share/i18n/SUPPORTED`, so I'd guess that it really
doesn't matter which architecture the package was built for.

In that case, is :native actually the correct solution here?

On reflection, I suspect that trying to get udebs to be cross-buildable
may indicate OCD tendencies on my part -- perhaps I should have just
disabled the test instead? (I'm assuming that the debian-cross list is
the place to find a justification for cross-building components of
Debian-Installer :-) )

> Feel free to reply publicly on debian-cross@lists.debian.org, if you like.
> Thanks!
> cheers, josch

Thanks again for your enlightening reply.

Cheers, Phil.
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

Attachment: signature.asc
Description: PGP signature

Reply to: