Bug#930961: gsoap is wrongly marked Multi-Arch: foreign

[Mattias Ellert]

sön 2019-06-23 klockan 17:47 +0200 skrev Helmut Grohne:
> 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

Hi Helmut.

Option 2 was implemented. All packages except for virtualbox either do
not need changes or have been fixed. If you could file the bug for
virtualbox I would appreciate it.

gsoap:
  - Remove libgsoap-dev dependency from gsoap
  - Fixed in 2.8.75-2

cgsi-gsoap:
  - Build-Depends on libgsoap-dev, does not use gsoap
  - No change needed

davix:
  - Add Build-Depends on libgsoap-dev
  - Fixed in 0.7.4-1

gridsite:
  - Add Build-Depends on libgsoap-dev
  - Fixed in 3.0.0~20180202git2fdbc6f-2

lcgdm:
  - Build-Depends on libcgsi-gsoap-dev, which Depends on libgsoap-dev
  - No change needed

srm-ifce:
  - Build-Depends on libcgsi-gsoap-dev, which Depends on libgsoap-dev
  - No change needed

voms:
  - Add Build-Depends on libgsoap-dev
  - Fixed in 2.1.0~rc0-6

virtualbox:
  - Add Build-Depends on libgsoap-dev
  - NOT DONE YET!

Mattias



smime.p7s
Description: S/MIME cryptographic signature

Bug#930961: gsoap is wrongly marked Multi-Arch: foreign

[Helmut Grohne]

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