[pkg-wine-party] Bug#758291: Final preparations for Wine alternatives - design decisions
jre.winesim at gmail.com
Thu Jun 16 23:58:35 UTC 2016
Hi Mike and others who are interested
I'm working on the alternatives system (replace /usr/bin/wine, other
files in /usr/bin and the manpages with links pointing to either the
files from src:wine (default if both are installed) or
I've prepared the final changes which still can be tested in
wine-development. There are some design decisions to be taken, maybe you
have some other preferences here (technically they all work). For now I
pushed my proposed changes to my github repository:
https://github.com/jre-wine/wine.git -b jre/debsuffix
The files from src:wine need to be renamed to free the namespace for the
links. I propose a suffix *-stable*. The directories and packagenames
don't need to be changed.
In the packaging we currently have VERSION which is either empty or
"-development". For the proposed suffix I'd suggest an additional
*DEBSUFFIX* (being either "-stable" or "-development").
Alternative name ideas:
While at it, we might also rename my recently introduced VENDOR (e.g.
Currently the scripts wine, wineapploader and wineserver detect the
correct paths/names (wine or wine-development) during runtime. This
would need to be adapted e.g. with "readlink".
But instead I propose to just set this at build time (with BINDIR,
DEBSUFFIX and VERSION). Then the installed files and their sources are
As drawback you obviously can't use the script from the packaging
directly, and the packaging itself would be a littlebit more
complicated. But imo it's a net gain (we already do so for the winegcc
script). The sources for these scripts should be renamed to
*.in and have the executable bit removed.
The patches in d/p/development/ need to be adapted, too. Instead of
simply replacing "development" with "stable" I'd propose to use the
generic DEBSUFFIX. (Currently there is no name collision in the
upstream source, but we should bear that in mind when choosing a
variable name). I implemented this similarly to
Review of these patches would be welcome (I tested them successfully,
but I'm not a coder so I might have missed something). You'll find it
However I suggest to drop winegcc.patch: It applies to a script template
which afaics is only used for a wrapper *.exe to start the compiled
output *.exe.so with Wine. So it is relevant when actually running the
Of course there might be cases where it is necessary to run the exe with
the same Wine that was also used to compile it. But I assume this isn't
the case most times.
Dropping the patch instead would allow for running the exe on other
machines without requiring the specific wine-stable or wine-development
binary names. And it would be one patch less.
- Release wine 1.8.3-1 (with the changes I've pushed to git today,
needs a sponsor).
- Release wine-development 1.9.13 (next week) with these or similar
- Implement alternatives system in wine (1.8.3-2) once both above
are in testing. Details later.
More information about the pkg-wine-party