Canonical and wine

Ben Klein shacklein at
Thu Dec 11 17:22:45 CST 2008

2008/12/11 Remco <remco47 at>:
> Canonical doesn't want to include Wine, because they are trying to
> provide a complete desktop experience. Wine is a necessity for many
> people, but Canonical wants to market Ubuntu as the Linux distribution
> that works well for normal usage. Including a half-working
> Windows-emulator (functionality emulator) doesn't fall within that
> mission. It gives the message that Ubuntu on its own isn't ready (true
> or not). Why would they want to switch from a good product (Windows)
> to an inferior one with spotty support for Windows applications?

I agree that Wine should not be a part of *buntu as standard. We have
enough problems in #winehq with new users already. So many people
think that Wine will "just work" for them, and are annoyed at Wine
devs when they discover it doesn't.

What Wine needs before being considered as suitable for a distro like *buntu is:
1) Near-completeness so that things "just work"
2) When things don't work, some way for a newbie to fix it easily
(with minimal assistance), or
3) Some easy-to-read, attractive basic *nix command line tutorial.
"How do I get the console output?" is one question being asked too
often by newbies, and the other day someone asked if they should
change the "cd /media/cdrom0" command to read "dvd" for their
particular installer.

I think it's fair to say that all three things in that list will
happen somewhere between a long time from now and never.

2008/12/12 Steven Edwards <sedwards at>:
> On Wed, Dec 10, 2008 at 3:42 PM, Zachary Goldberg <zgold at> wrote:
>> I believe it has been proposed before to have .debs for things like
>> Adobe Photoshop which first install Wine (or create a new prefix etc.)
>> and then ask for the Photoshop CD; sort of like application specific
>> bundlings of Wine.
> This has been the long term plan we've had with Bordeaux. We
> ultimately want to give the user the ablity to just do something along
> the lines of
> sudo apt-get install photoshopcs
> and have it find the correct version of Wine, if its missing install
> that deb, install the photoshopcs deb and then start the install
> process.

Why does this sound like a bad idea? The first thing that comes to
mind is when Wine gets updated, the system's Wine-version/application
compatibility list would have to be updated with it. I'm also not too
keen on the idea of adding a bunch of packages for proprietary
software arbitrarily. Perhaps a separate Wine applications manager
would be a solution (and this idea sounds like Cedega/PlayOnLinux)?

> There are a few key pieces missing for this to work
> well for the end user though.
> 1. Wine Prefix Management
> <-- snip -->
> /usr/local/wineprefixes for the global prefixes

One word: permissions. Current wine refuses to run if its wineprefix
is not owned by the current user. Though this problem could be solved
by creating a special "wine" user and group for the global prefixes,
and su'ing into that user before a global prefix is used, it could get
messy to manage when there are local prefixes too.

> Also when dealing with things like deb/rpm packages the prefix manager
> will need to know how to handle these.

It should be relatively simple to have the package call an appropriate
script for generating a prefix with a sensible name etc. The problem
would come when trying to install Windows software manually, or
perhaps a wrapper script/tool could be supplied for this too.

> 2. Templates
> The ultimate goal is of course that it will just install out of the
> box with no dependencies, fonts or wine dlloverride tricks. This is of
> course not possible in every case and so we need to take this in to
> account.

This is PlayOnLinux-type stuff and subject to my earlier comment about
when Wine gets updated.

> 3. We need some sort of tool like you said that prompts for a CD. Some
> sort of autorun.exe like tool. Ubuntu has been working on this so that
> a Wine CD is identified and offered to start the setup.exe or
> whatever. Its very generic and not very effective. We need a better
> way.

Remember: it's not safe or *nix-like to automagically run software on
media that has just been installed. Fortunately we're talking about
on-demand install disc here (install the package, package says "Please
insert <application name> install disc").

One problem you missed is a sensible way to keep multiple versions of
Wine on the system as needed. This could get extremely messy; the best
solution would be to keep a database of all known-working Wine
versions for all supported applications, and install only the minimum
set required to get those applications that you install working. With
each new version of Wine and application, the set will likely change,
and you'd need some wrapper script in order to know which installed
version of Wine to run for a particular application. Not to mention
the additional manpower required to maintain the database, and any
additional things required (like winetricks stuff that's required for
some versions of wine but not others).

With this concept, would hacky-patched Wine versions be supported,
e.g. the ddraw hack to get Worms Armageddon and Diablo 1 working, or
the capabilities hack to get Call of Duty and 3dmark working? My guess
is probably not :)

More information about the wine-devel mailing list