Package: juce-modules-source Version: 5.4.7~ds0-2 Severity: important User: debian-cr...@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