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