Wine: New Packaging

Wine (Wine Is Not an Emulator) is an application that allows Windows software to run on Linux. This article deals with installing, configuring, and maintaining a general purpose Wine environment on Gentoo.

Packaging Details
As many Wine users know, there are often regressions or an application works better on one version of wine than another. Going forward, packaging in Gentoo will allow simultaneous installation of multiple versions of Wine.

Additionally, to expedite vanilla releases as well as permit multiple configurations for each Wine installation, the major patchsets have been split out into separate packages.

Quick Start
For most users, worrying about the various packages and what they do should not be a concern. The split packaging and slotting is a power user feature, and most users will be OK with simply installing, which chooses which wine version for the user.

Wine Variants

 * upstream Wine with no external patchsets
 * (like if the old packaging forced USE="-staging -d3d9")
 * Wine with Wine-Staging's patchset
 * (like if the old packaging forced USE="+staging -d3d9")
 * Wine with Ixit's Gallium Nine patchset
 * (like if the old packaging forced USE="-staging +d3d9")
 * Wine with any of the patchsets or flags
 * (exactly like the old packaging regarding USE flags)
 * wine-any exists to allow the user to build any combination that they'd like (like the old packaging). This means the user could use wine-any to use both Wine-Staging and Gallium Nine.  Alternatively, the user could use wine-any to try out another configuration from other packages.  For example, the user could build wine-vanilla without PulseAudio, and could build wine-any with PulseAudio.  The sky is the limit on how a user may choose to use app-emulation/wine-any.

Choosing a variant
Shouldn't I just choose wine-any, even if I'm not going to use all of its flags?
 * The answer to that is a resounding no.  manages selection of of a variant in such a way as to provide the best experience to the user.  Most users don't want to be dealing with external patchsets.  External patchsets may introduce bugs that don't exist in the vanilla Wine release and can make using Wine more complicated for the user.  External patchsets also can be released up to a week or two after vanilla wine (or each other), meaning that the period for releases can be significantly slower for those using, , or.

What if I want to manually choose a variant anyway? Which should I choose?
 * This really isn't a question that the authors of this document can answer. Typically, the logic works as follows:
 * Unless you need something more, choose.
 * If your application requires advanced features only available in Wine-Staging, choose.
 * If you do research online and find that Wine-Staging provides better performance for your application, choose.
 * If you do research online and find that Gallium Nine provides better performance for your application, choose
 * If you do research online and find that you need Wine-Staging features and Gallium Nine for your application, choose
 * If you have built another variant with a USE flag set and want to try an alternative flag set, like using Gstreamer on and wanting to use PulseAudio on the same version, choose  in addition to your other variant choice.

Environmental variables
Traditionally, live (9999) ebuilds support setting the repository commit as an environmental variable. This poses some issues with an ebuild that has multiple upstream repositories. To work around this issue, Wine's live ebuilds support 3 environmental variables for individually configuring the commit that each repository checks out. The WineHQ repository is controlled by WINE_COMMIT, Wine-Staging repository by STAGING_COMMIT, and Ixit's Gallium Nine repository by D3D9_COMMIT. The *_COMMIT variables may contain either a commit hash from that repository or a git tag from that repository.

For example, one could select the WineHQ tag "wine-2.0-rc5" to emerge the 2.0 RC 5.

One could additionally pin Wine-Staging to the same release by finding the appropriate tag, "v2.0-rc5" and augmenting the previous as follows:

Other environmental variables, which affect Wine at runtime, are discussed below.

Emerge
Enable the USE flags of choice and the package:

To install the latest development version of Wine the package needs to be individually unmasked:

The above command does not apply to systems that have defined globally in the ACCEPT_KEYWORDS variable located in

Disabling the menubuilder
To prevent Wine from adding menu entries and desktop links, the following override can be used:

Previously added entries can be deleted by removing the corresponding files from. See Wine FAQ for examples.

Tools and interfaces
Tools such as graphical interfaces for Wine can be helpful for users who want an alternative to the command-line:


 * – Qt4 GUI configuration tool for Wine.
 * – Wine-doors is a package manager for Wine.
 * – Easy way to install DLLs needed to work around problems in Wine.
 * – Set of scripts to easily install and use Windows games and software.

Runtime environment variables
The environment variables of the shell that is started from are made accessible to the Windows/DOS processes. Some very useful Wine-specific variables include, but are not limited to, WINEPREFIX, WINEARCH , and WINEDEBUG.

See the and  manual entries for more detailed information concerning Wine's environment variables.

WINEPREFIX
To create a Wine prefix in a custom location without affecting the default:

The above would create the Windows installation in the home path of the user, under.

WINEARCH
To create a 32-bit installation instead of the default (when built) 64-bit:

The Wine executable used could be anything that runs Wine, such as, which often makes sense while creating a clean, new prefix.

To use 32-bit windows programs on a 64-bit linux-system you must set the USE-Flags abi_x86_32 and abi_x86_64 for wine and all packages needed by wine (can be do automaticaly). I have set this flags in make.conf and remove it for some packages in package.use which won't be emerged with both flags.

WINEDEBUG
Essential in finding out why an application is misbehaving when the basic terminal output or messages boxes are not enough. See Debugging for examples.

Troubleshooting
When a user encounters a problem with an application, they should try the latest development version to see if the unwanted behavior still exists. If Wine has been built with options such as  or , the Wine developers will likely be unable to help with the issue, and reports including output from such builds should not be reported to the Wine Bugzilla.

The  USE flag should be enabled for debugging builds.

For more directions on reporting bugs, see Bugzilla and Bugs at wiki.winehq.

Support
Users may find additional support in the #gentoo-wine channel on Freenode.

Packaging Notes
Version 1.9.24 was skipped due to a lack of a staging release

Wine-Staging in >=wine-2.0
Starting with the release of =wine-2.0, the "staging" and related USE flags will not be available for stable branch wine ebuilds. This means that wine-2.0* will not have staging available, but versions >=wine-2.1 and <wine-3.0 will. Through a special arrangement with the Wine-Staging developers, staging tarballs were created for the previous stable branch, but after some discussion, it was decided to terminate this going forward because Wine-Staging, by definition and mission, is staging quality, not stable. Though Wine-Staging released a tarball for =wine-2.0, it will not be packaged, to provide consistency with the Gentoo stable packaging going forward.

Upcoming packaging changes
Soon, a rework of the wine package will be released for Gentoo which allows multiple installations in parallel. What this means for users is that if they have an application that only works on a particular version of wine, they can install that version along side any other version. Additionally, wine will be split into several packages. Currently, the intention is to have "wine-vanilla," "wine-staging," and "wine-d3d9" packages so that users can also use multiple patchsets in parallel. Management of the default wine installation will be handled with an eselect module.

External resources

 * – Wine related bugs.
 * WineHQ Wiki
 * Wine Application Database – Search for the game or program to install here to see if it is stable.