Package: gsoap Version: 2.8.75-1 Severity: important User: debian-cr...@lists.debian.org Usertags: ftcbfs Control: affects -1 + src:voms
gsoap is one of those packages that combines a tool with a shared library (libgsoap-dev). The gsoap package is marked Multi-Arch: foreign, so when it ends up in Build-Depends, the build architecture instances is chose. This transfers to its dependency libgsoap-dev. However voms needs the host architecture libgsoap-dev. This is wrong. Presently, gsoap exposes libgsoap-dev for is wrongly marked Multi-Arch: foreign for this exposure. I see the following options to fix this: 1. Remove Multi-Arch: foreign. (<- This is bad. I hope obviously.) 2. Drop the dependency from gsoap to libgsoap-dev. Thus gsoap no longer exposes libgsoap-dev. Doing so makes a number of packages (including voms) FTBFS until they add a dependency on libgsoap-dev. However this is the approach chosen by flex (and libfl-dev) and bison (and libbison-dev). This is doable and consistent with other packages. Of course this is not reasonable before buster is out of the door. 3. Flip the dependency. This one is tricky. We remove the dependency from gsoap to libgsoap-dev. Then, we rename gsoap to gsoap-bin. Then we rename libgsoap-dev to gsoap and add Provides: libgsoap-dev to the new gsoap. The new gsoap also Depends: gsoap-bin. Effectively the dependency is reversed. The entry point no longer is Multi-Arch: foreign, but Multi-Arch: same instead. This approach is used by qt5-qmake. gsoap has a total of 7 build-rdeps in main. That's a strict upper bound to the number of FTBFS option 2 can introduce (i.e. few). Please tell me which option you prefer. If you choose option 1, I'm sad. If you choose 2, I can prepare and/or perform the filing of the FTBFS bugs. If you choose 3, I can prepare a patch for gsoap. If you have no clue, don't ask for help with better understanding the situation. Helmut
