[ 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 hand. 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