Bug#949791: can foomatic-db-engine be marked Multi-Arch: foreign?
Package: foomatic-db-engine
Version: 4.0.13-4
User: debian-cross@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
Reply to: