Comment 30 for bug 1558480

Revision history for this message
jre (jre-phoenix) wrote : Re: Make Wine packages synced from Debian

Great, bryanquigley! You might get in contact with ginggs who's also working on this.

1.) Breaks/Replaces:
Test all packages (e.g. wineNN-tools, libwine-dev, wineNN-preloader). The -tools may be installed without "wine" itself, so you shouldn't rely on breaks/replaces in wine/wineNN itself.
(At least in the long run) you should add "1:" to every versioned breaks/replaces in d/control.in.

2.) Dependencies (dh_shlibdeps):
> * Comment out override_dh_shlibdeps in rules which fails with:
> /usr/bin/ld: cannot find libGL.so.1
> (*I believe this will be fixed in yakkety as we pull the latest debian build stuff)

[This code is for generating some dependencies that are only used with dlopen. See https://bugs.debian.org/823991 (libwine: Does not declare a Depends: on libpng)]

It would be great if yakkety automatically fixed that, but I doubt it. ginggs and I have been looking into this. Best fix I found was to make the sonames (that dh_shlibdeps looks for) unversioned. See:
- bugs.debian.org/827770 (wine-development: FTBFS in Ubuntu)
- https://lists.debian.org/debian-mentors/2016/07/msg00148.html

Looking for unversioned sonames normally still should get the correct dependencies, but I guess it has the potential for a regression, so I don't want to just add this in Debian. wine-WorkaroundShlibdepsSonames.patch attached.

If that gets fixed, there's still a related ftbfs on armhf:
- https://lists.debian.org/debian-arm/2016/07/msg00090.html

If you simply workaround this by commenting the code, you indeed should manually add some dependencies. I recommend libfontconfig, libfreetype and libncurses (the dh_shlibdeps code in Debian generates a libwine *depends* on them on each architecture, otherwise you'd usually have them only installed on your host arch). The same code also generates a libwine *recommends* for a lot of dependencies, one of them libpng.

Once libfreetype6:i386 is installed, do you really need the two fonts- packages? Not sure if Korean and Japanese fonts should be pulled by wine. If you use these languages, doesn't something more relevant pull them in?

3.) wine32:
As bryanquigley said wine depends on wine32|wine64, and wine64 recommends wine32. So wine tries hard to get wine32, but doesn't enforce it. However (as long as you are using wine in the terminal) it will show you the mentioned message, or (only on *amd64* with i386 not enabled as foreign arch) it will also output instructions how to add the foreign arch. See /usr/bin/wine (https://anonscm.debian.org/git/pkg-wine/wine.git/tree/debian/scripts/wine.in) for details.

In Debian we want to be able to install wine without having i386 enabled as foreign arch:

- There are valid use cases for installing only 64-bit wine.
- I assume telling the users how to enable i386 from /usr/bin/wine has more potential to help them, then to enforce it before installation (and putting the information in the package long description). Automatically adding i386 is not wanted and afaik not possible.

@scottritchie: Was it possible to install wine1.6 without i386 as foreign arch?

@dino99:
> E: Unable to correct problems, you have held broken packages.
The wine packages need to be of the exact same version. If you have e.g. libwine:i386 on hold, then the other packages depending on it will be broken.