2008/12/11 Remco remco47@gmail.com:
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@bordeauxgroup.com:
On Wed, Dec 10, 2008 at 3:42 PM, Zachary Goldberg zgold@bluesata.com 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.
- 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.
- 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.
- 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 :)