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

Re: The :native qualifier for cross building

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

 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.


cheers, josch

Attachment: signature.asc
Description: signature

Reply to: