Package: foomatic-db-engine Version: 4.0.13-4 User: debian-cr...@lists.debian.org Control: tags -1 + moreinfo Usertags: ftcbfs Control: affects -1 + src:foo2zjs
Hi Didier, foo2zjs fails to cross build from source, because it fails running foomatic-perl-data and foomatic-combo-xml with an "Exec format error". Usually that means that it needs the corresponding package (foomatic-db-engine) for the build architecture rather than the host architecture. The simplest way to do that is marking foomatic-db-engine Multi-Arch: foreign. Unfortunately, sometimes such a marking is wrong and that can cause breakage elsewhere, so one should be careful not to blindly add it. To understand whether it is correct, one needs someone with deep multiarch and foomatic knowledge to look at it. Unfortunately, I think there are about zero persons on this planet that match the criterion. For instance, I certainly lack the foomatic knowledge. So let's try the second best approach: Have someone with multiarch knowledge talk to someone with foomatic knowledge. Can I ask you to be the one who talks about foomatic? The question to ask here is: If I'm installing foomatic-db-engine one a different computer with a different architecture, would i notice any difference when interacting with the provided interfaces? In this case interfaces are non-private components contained in foomatic-db-engine. Typically the contained programs (/usr/bin/*) count towards the interface. For the shipped perl modules it is less clear. Sometimes, packages ship private perl modules. Are the perl modules shipped in foomatic-db-engine considered public? If you consider them an implementation detail and no other package uses them, we can disregard them for our analysis. I suppose that printing stuff generally operates with architecture-independent file formats. Is that the case here? For instance textual file formats (such as xml) are generally assumed to be architecture-independent. Is there some way of learning the processor architecture, bits or endianess by interacting with these tools? (Note that inspecting the binary files with binutils does not count here.) We also need to look into dependencies. Sometimes packages wrap other packages (e.g. foo depends on foo-data, but foo-data's content generally counts towards the interface of foo as foo-data is an implementation detail to save archive space). The dependencies to consider here are cups-filters | foomatic-filters, wget | curl and possibly perl. I guess perl is being added by debhelper due to the perl module. wget and curl are also used by the perl module. So how about the filters? Are they used internally or exposed? Possibly we need to consider whether cups-filters can be marked Multi-Arch: foreign, before we can come up with an answer for foomatic-db-engine. This is not one of the bugs where you can blindly apply a patch unfortunately. Please help me find the correct solution. Helmut
