Bug#979169: juce-modules-source is wrongly marked Multi-Arch: foreign

[Helmut Grohne <helmut@subdivi.de>]

Package: juce-modules-source
Version: 5.4.7~ds0-2
Severity: important
User: debian-cross@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:giada

juce-modules-source is wrongly marked Multi-Arch foreign. It has runtime
dependencies on C development packages in a way that exposes them.
However, the foreign marking masquerades the architecture constraint.
The options out of this mess are dim:


1. Apply the "multiarch interpreter workaround". An Arch:all +
   M-A:foreign package affected by the "multiarch interpreter problem"
   (which is the case here) can often be converted to Arch:any +
   M-A:same. Doing so wastes resources and here it would be duplicating
   18MB for each architecture.

2. The problem here is that juce-modules-source depends on e.g.
   libxfixes-dev and consumers expect this dependency to be available. A
   solution therefore would be demoting all dependencies to recommends
   and requiring downstream packages (such as giada) to list all those
   dependencies explicitly if they need them. This gives a little more
   flexibility, but comes at more maintenance cost.

3. If the "multiarch interpreter workaround" is deemed too wasteful, the
   package can be split. The actual data is moved into a separate
   juce-modules-source-data package which can stay Arch:all +
   M-A:foreign. The juce-modules-source package becomes Arch:any +
   M-A:same and depends on juce-modules-source-data. Being Arch:any
   ensures that the architecture constraint can be passed down to -dev
   packages and the split keeps the archive space low. Of course, this
   variant grows the metadata cost as it adds a package.

None of these is particularly attractive. Do you have any preference?

Helmut