[pkg-wine-party] Wine packaging (was Bug#585409:Please packagewine1.2 series)

Thu Apr 12 06:14:26 UTC 2012

On Sun, 18 Mar 2012 08:57:29 Ove Kåven wrote:
> My objectives before packaging 1.2 included:
> 
> 1) Coinstallability of wine and wine-unstable. The steps involved includes:
> - use separate directories for wine and wine-unstable (done)
> - make sure Wine's build system uses the correct directories (done)
> - add -unstable suffix to /usr/bin binaries (done)
> - use Debian's alternatives system to choose whether to use wine or
> wine-unstable (mostly done)
> - make sure Wine (and Winelib wrappers) always launches the correct
> version of itself for subprocesses (not done)
> - decide on a policy for winemenubuilder etc (not done)
> 
> 2) Coinstallability and interoperability of 32-bit and 64-bit Wine.
> Combined with the above, this implies that 4 versions of Wine can be
> installed on the same system.
> - packages must build on multiarch; on multiarch, a 64-bit build cannot
> build 32-bit wine (mostly done, need to flip a switch in debian/rules
> and fix problems)
> - for backporting, the packages must also build on non-multiarch, in
> which case a dpkg-buildpackage should build both 64-bit and 32-bit (a
> backporter should only have to flip that switch in debian/rules back in
> order to get this, or better, perhaps debian/rules could autodetect
> somehow) - use separate directories for 32-bit and 64-bit wine (mostly
> done) - add 32 or 64 suffix to /usr/bin binaries (mostly done)
> - use Debian's alternatives system to choose whether to use 32-bit wine
> or 64-bit wine by default, should be same system as wine/wine-unstable
> above (mostly done)
> - Wine must work if either or both versions are installed, and the
> correct one should run if the user runs wine32 or wine64, including
> subprocesses. Also keep in mind that the user's WINEPREFIX may contain a
> fake a 32-bit or a fake 64-bit Windows installation, depending on
> whether the 32-bit or 64-bit Wine created it; you cannot run a 64-bit
> Wine instance on a 32-bit WINEPREFIX, so always defaulting to 64-bit is
> not an option. (not done)
> - Even if the 64-bit Wine is default, it would be nice if Wine
> automatically ran its 32-bit version if it was asked to run a 32-bit
> program, and in this case, emulate 64-bit Windows's WOW32 (32-bit
> Windows emulation). Needs to work with multiarch, and fail gracefully if
> wine32 is not installed. (not fully investigated)
> 
> There might be more, I can't quite remember.

Hi Ove (and others),

I've been looking at the current packaging scripts and hacking on them a bit 
to try to work towards these goals.

Note: I'm quite new to the idea of Multiarch and haven't been involved with 
Debian packaging for very long, so please excuse me for sounding noobish!

I've got some questions about Multiarch wine, the current debian/rules, and 
the best way to go forward:

- Firstly, what is your policy on building Wine64? debian/rules contains a 
comment saying that it is not really ready (and for 1.1.37 it may not be), but 
shouldn't it be built anyway for multiarch on wheezy/sid? Is it okay that if a 
user on amd64 wants 32-bit wine they have to install wine:i386 ?

- How should dependencies work for wine:amd64 ? It would be nice to enable 
WoW64 which requires 32-bit binaries. Should we be looking at something like 
'Depends: libwine:i386, libwine-bin:i386, wine-bin-i386' for wine on amd64 
(from [1])? The other option I see is to include the 32-bit binaries in the 
64-bit package (given as an option in debian-policy[2], though it would be 
much cleaner to avoid doing this).

- Is there any point in supporting partial architectures (I see that there is 
some support in debian/rules)? If so, what is the use case? Why not just make 
MULTIARCH=(y|n)?

- Regarding the WINEPREFIX issue, would it be enough to set the 
WINEPREFIX=$HOME/.wine32 or WINEPREFIX=$HOME/.wine64 in the wrapper script, 
based on the current architecture? Or even just set the special WINEPREFIX for 
wine64?