Hi Phil, Quoting Philip Hands (2022-09-19 11:40:19) > 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 think the problem there is, that it's quite hard to parse FTBFS error messages and turn them into the correct advise for package maintainers, telling them what they can do to fix them. > 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. I think the interesting question for us would be to know where you would have expected to find this information? Where did you look and found what you now know to be missing? > > 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? There are multiple solutions to this problem and that is yet another reason why it's really hard to give automated advice for where to find the right explanation for what would fix their problem. a) since locales is Arch:all and cannot be marked M-A:foreign, you can attach :native to tell the resolver "I know that the interface of this package is not architecture independent but I hereby am telling you that I really know what I'm doing!" b) turn locales from an Arch:all into an Arch:any package. Then building the package would draw in the host architecture locales package and the resolver would be able to pick a solution. Unfortunately, the locales package also ships programs in /usr/sbin which are executed as part of its postinst. We (usually) cannot run these foreign-arch binaries, so you would now get a failure a little bit later. Another problem would be that the native arch locales and foreign arch locales would not be co-installable. So this is a non-option. c) split the locales package into a part that exposes its architecture dependent interface and a part that only exposes an architecture independent interface. The latter can contain /usr/share/i18n/SUPPORTED (and probably other stuff) and the package containing these data files can then likely by marked M-A:foreign. The locales package can then depend on the locales-data package and you can replace your build dependency on locales to a build dependency on locales-data that can now be fulfilled because locale-data will be M-A:foreign. Option c) has to be coordinated with the glibc maintainer and is probably a question about how many other consumers of such a locales-data package exist out there. Thanks! cheers, josch
Attachment:
signature.asc
Description: signature