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 src:wine-development).
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: DEB_SUFFIX SUFFIX While at it, we might also rename my recently introduced VENDOR (e.g. DEBVENDORVERSION). 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 easily readable. 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 https://github.com/wine-compholio/wine-staging/tree/master/patches/winemenubuilder-Desktop_Icon_Path. 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 at: https://github.com/jre-wine/wine/blob/jre/debsuffix/debian/patches/debsuffix/winemenubuilder.patch 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 compiled output. 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. Proposed roadmap: - 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 changes. - Implement alternatives system in wine (1.8.3-2) once both above are in testing. Details later. Greets jre