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

[Austin English]

On Thu, Apr 12, 2012 at 01:14, Scott Leggett <scott at sl.id.au> wrote:
>
> 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)

Wine itself handles this. Users should only invoke 'wine' directly. If
only wine32 is installed, that is what is run. If both are, wine
determines if it is a 32 or 64 bit binary and acts accordingly.

>> - 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)

See above.

>> 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?

Wine64, on its own, is pretty useless. It can only run 64-bit
binaries, which are relatively rare (most 64-bit programs include at
least some 32-bit stuff).

Users _need_ wine32. Whether they also want wine64 is optional.

Keep in mind, my comments are from wine's point of view. I can't speak
about the packaging process/opinions.

> Other random questions:
>
> - The current monolithic .diff.gz is a little difficult to grok.. are there
> any plans or objections to move towards a quilt system?
>
> Any opinion you can give would be much appreciated.
>
> --
> Regards,
> Scott.
>
> [1] http://wiki.winehq.org/Wine64ForPackagers
> [2] http://www.debian.org/doc/debian-policy/ch-opersys.html#s-fhs
>
> _______________________________________________
> pkg-wine-party mailing list
> pkg-wine-party at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-wine-party


-- 
-Austin