If you decided that you can use and want to use Wine (e.g. after having read the introductory chapter), then as a first step you need to find a good compatible Wine version that you like and that works on your system, and after you found one, the next step is to transfer its files to your system somehow. This chapter is here to tell you what you need to take care of in order to successfully accomplish these two steps.
There are three different methods of how the files belonging to Wine may be brought (downloaded) to your system:
Getting a single Wine package file (specifically adapted to your particular system), which contains various binary files of Wine
Getting a single compressed archive file (usually .tar.gz), which contains all source code files of a standard Wine release version
Downloading from a CVS server, which contains the very latest development source code files of Wine
Now that we told you about the different Wine distribution methods available, let's discuss the advantages and disadvantages of the various methods.
Wine distribution methods
Intended user level: Beginner to Advanced
Using Wine package files is easy for three reasons: They install everything else that's needed for their operation, they usually preconfigure a lot, and you don't need to worry about compiling anything or so. However, the Wine Team doesn't have "official" packages. All Wine packages are being offered by external groups, with often slightly inaccurate or quite inaccurate Wine environment setup. Also, a package you downloaded might turn out to be partially incompatible with your particular system configuration. Thus it might actually be better to compile Wine from source and completely install it on your own, by following the instructions in this Guide.
Intended user level: Advanced to Expert
A Wine source code archive file can be used if you want to compile your own standard Wine release. By using differential patch files to newer Wine versions, you can easily upgrade your outdated Wine directory. However, as you need to manually download patch files and you're only able to download the most current standard Wine release, this is not necessarily the best method to use. The only advantage a Wine source archive has is that it is a standard Wine release with less development "quirks" than current CVS code. Except for that, CVS source code is much preferred and almost as easy.
Intended user level: Advanced to Expert/Developer
The Wine CVS checkout offers the best way to take part in bleeding edge Wine capabilities and development, since you'll be able to download every single CVS commit even beyond the last official Wine release. As upgrading a Wine CVS checkout tree to the latest version is very easy, this is a recommended method of installing Wine. Plus, by carefully following the instructions in this Guide, you'll be able to gain the very best Wine environment compatibility (instead of falling victim to package maintainers who fail to follow some instructions in the Wine Packagers Guide).
To summarize, the "best" way to install Wine is to download Wine source code via CVS to get the newest code (which might be unstable!). Then you could easily compile and install the Wine files manually. The final configuration part (writing the configuration file and setting up the drive environment) could then be handled by WineSetupTk. All in all the best way to go, except for the about 500MB of disk space that you'll need.
With source code archive files, you have the advantage that you're running standard release versions, plus you can update to newer versions via patch files that we release. You won't have the newest code and the flexibility offered by CVS, though.
About binary package files: not sure. There's about a zillion reasons to not like them as much as you'd think: they may be outdated, they may not include "everything", they are not optimized for your particular environment (as opposed to a source compile, which would guess and set everything based on your system), they frequently fail to provide a completely configured Wine environment. On the plus side: they're pretty easy to install and they don't take as much space as a full-blown source code compile. But that's about it when it comes to their advantages. So I'd say they are OK if you want to have a quick way to have a test run of Wine, but for prolonged Wine use, configuring the environment on your own is probably better. Eventually this will change (we'll probably do some packaging efforts on our own at some time), but at the current explosive rate of Wine development, staying as close as possible to the actual Wine development that's going on is the way to go.
If you are running a distribution of Linux or some other system that uses packages to keep track of installed software, you should be in luck: A prepackaged version of Wine should already exist for your system. The following sections will tell you how to find the latest Wine packages and get them installed. You should be careful, though, about mixing system packages between different distributions, and even from different versions of the same distribution. Often a package will only work on the distribution which it has been compiled for. We'll cover Debian Linux, Red Hat Linux, FreeBSD, and other distributions.
If you're not lucky enough to have a package available for your operating system, or if you'd prefer a newer version of Wine than already exists as a package, you will need to download the Wine source code and compile it yourself on your own machine. Don't worry, it's not too hard to do this, especially with the many helpful tools that come with Wine. You don't need any programming experience to compile and install Wine, although it might be nice to have some minor UNIX administrative skills. Working from the source is covered in the Wine Developer's Guide. The main problem with externally maintained package files is that they lack a standard configuration method, and in fact they often fail to configure Wine's Windows environment properly (which is outlined in the Wine Packagers Guide).