[pkg-wine-party] Bug#758291: Wine alternatives - last design decisions

Jens Reyer jre.winesim at gmail.com
Mon Jul 25 02:38:57 UTC 2016

Hi all!

Here's a proposal to implement the wine alternatives. (The manpage
update-alternatives(1) imo is the best reference for this.)

The Debian alternatives system uses one master and additional slaves. As
master I'd suggest "wine" (/usr/bin/wine). As slaves all other commands
in /usr/bin/ and their manpages.

The alternatives system would then be handled by the wine(-development)
binary package. Unfortunately some slaves are not in there, but in
wine64(-development) or wine{32,64}(-development)-tools.

If these packages are not installed, the corresponding slave alternative
links will simply not be installed. Per default update-alternatives will
display a warning then, but I'd suggest to use "--quiet" (Don't generate
any comments unless errors occur).

I added file triggers[1] on a file in each of these packages. These are
activated automatically by dpkg when a matching file is installed,
upgraded or removed as part of a package. The wine(-development) package
is then triggered to update the alternatives, so there won't be any
broken or wrong links.

[1] /usr/share/doc/dpkg-dev/triggers.txt.gz

If wine(-development) is not installed, the other packages still work,
but their commands are only available with suffix (-stable or -development).

wine64 already recommends wine. I propose to also let the -tools
recommend wine. I assume that nearly everybody who installs the -tools
also installs wine anyway. The packages wine, wine32 and wine64 together
have a installed size of only about 1 MB. However (once it's available
and recommended by wine) libwine-gecko has about 45MB. This is a
regression for users of the -tools packages, who don't want to install
wine(-development). But I think that's ok.

Alternatively we might add a new package wine-dummy that only ships the
alternatives system with a dummy script as master, and add "Depends:
wine|wine-dummy" to all slaves packages. I didn't try this yet, because
I'd like to avoid the extra package and the dummy script.

Or alternatively we could add a separate alternative system for the
-tools packages, with e.g. "winegcc" as master. But I assume that would
only help a very small minority of users.

In the attached patch there are 2 DEBUG lines and "--quiet" is not
specified, I'd change that before committing. I'd also rename
development/*.patch to debsuffix/*.patch, and drop winegcc.patch (see my
previous mail in this bugreport).

I will commit this to master and (slightly adjusted + the other relevant
changes) to stretch, in a few days for easier review.

Alternatively I might just commit to stretch for now, so that we could
first release wine, to have another round of testing.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: wine-alternatives.patch
Type: text/x-patch
Size: 9255 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-wine-party/attachments/20160725/e0f4915d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-wine-party/attachments/20160725/e0f4915d/attachment.sig>

More information about the pkg-wine-party mailing list