[pkg-wine-party] Bug#823264: wine32-tools: Allow installation on amd64 with 64-bit tools

[Jens Reyer]

control: retitle -1 wine32-tools: Allow installation on amd64

On 05/02/2016 08:56 PM, Javier Serrano Polo wrote:
> Package: wine32-tools
> Version: 1.8.1-2
> Severity: wishlist
> 
> This is somewhat related to https://bugs.debian.org/807926 .
> wine32-tools works with gcc-multilib and perl from amd64. Adding this
> type of dependency should work:
> 
>         Depends: gcc | gcc-multilib:amd64 [amd64], perl | perl:amd64
>         [amd64]

Thanks for the hint! Unfortunately there are some issues:

1.)
"[amd64]" seems to be related to the build host. Since wine32-tools is
built on i386 the expression simply is omitted.
Solution: simply omit.


2.)
*Theoretically* speaking: gcc-multilib is not multi-arch'ed [1]. For
"gcc-multilib:amd64" it would need to be "allowed", for omitting the
arch and just installing it from the host arch it would need to be
"foreign".

Quoting https://wiki.ubuntu.com/MultiarchSpec:
  Multi-Arch: no
  The package is not co-installable and it must not be used to satisfy
  the dependency of any package of another architecture than its own.

Other packages of the same source package have multi-arch fields, so I
assume there is a reason that this has none. But I have no real
knowledge about gcc in general and gcc-multilib in particular.

*In practice* it seems to work. Not sure if I'm wrong, or the tools
(tested with aptitude) permit things that they shouldn't.

[1]: See
https://tracker.debian.org/media/packages/g/gcc-defaults/control-1.161


3.)
The dependency on perl originates from "${perl:Depends}". If we just
added "| perl:amd64" this would break if the variable gets expanded to
several values. Just using "perl|perl:amd64" might be ok, but omitting
the variable sounds wrong to me.
At least perl is "Multi-Arch: allowed", so your suggestion works otherwise.


4.)
Finally, even if we got this working, co-installability of wine32-tools
and wine64-tools is not possible atm. They need to conflict with each
other, because they use the same binary names in /usr/lib/wine/. We had
wrappers in the past for winegcc32 and winegcc64 for co-installability,
but I'd like to avoid the mess of doing this again, especially since the
packaging changed since then, and we'd have to do this for every
executable in the -tools packages. Therefore retitling this bug to
reflect the part that needs to be solved first (not sure anyway what you
exactly meant with "64-bit tools").

Final sidenote: there's no gcc-multilib for arm64 (the other 64-bit
architecture with Wine).


Below patch applies to the wine32VERSION-tools section of d/control.in.
With this I could install wine32-development-tools on amd64. If we
replaced "${perl:Depends}" with "perl" we might try it (but again, see
point 2 and 3). Opinions?

diff --git a/debian/control.in b/debian/control.in
index c2b8296..03f81fb 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -171,8 +171,8 @@ Architecture: any-i386 any-powerpc armel armhf
 Section: libdevel
 Built-Using: ${built:Using}
 Depends:
- gcc,
- ${perl:Depends},
+ gcc | gcc-multilib:amd64,
+ ${perl:Depends} | perl:amd64,
  ${misc:Depends},
  ${shlibs:Depends},
  libwineVERSION-dev (= ${binary:Version}),


Greets
jre