http://www.technewsworld.com/rsstory/65431.html quotes Gerry Carr, marketing manager at Canonical: "We aren't considering a pitch about using Wine or Parallels like on a Mac. There is no real look at Wine. It doesn't always work well. So this won't win over users to the benefits of Linux,"
So there you go. Canonical will think about Wine once it always works well.
On Wednesday 10 December 2008 19:09:16 Dan Kegel wrote:
http://www.technewsworld.com/rsstory/65431.html quotes Gerry Carr, marketing manager at Canonical: "We aren't considering a pitch about using Wine or Parallels like on a Mac. There is no real look at Wine. It doesn't always work well. So this won't win over users to the benefits of Linux,"
So there you go. Canonical will think about Wine once it always works well.
Sure. because only 'hardcore Linux users' use Wine. That's just what I see every day when I look into #winehq. Hardcore Linux users who never need help with the basic questions of compiling Wine from source or updating to the latest Wine release, but who are stopped from running their games^Wprograms by Wine.
Excuse me while I rush out to catch one of these flying pigs, Kai
On Wednesday 10 December 2008 19:09:16 Dan Kegel wrote: http://www.technewsworld.com/rsstory/65431.html quotes Gerry Carr, marketing manager at Canonical: "We aren't considering a pitch about using Wine or Parallels like on a Mac. There is no real look at Wine. It doesn't always work well. So this won't win over users to the benefits of Linux,"
So there you go. Canonical will think about Wine once it always works well.
I agree with Canonical that perhaps it doesn't make sense to make a Winebuntu or a new Ubuntu with Wine as a bigger focus for exactly that reason, it doesn't work for everything and that isn't a great experience. (Anything thats inconsistent is bad for something like Ubuntu. We love Wine but fact is fact, it isn't univerally perfect so they can't advertise 'Full Windows Application Support!' etc. etc. They could advertise 'Will Work with Some Windows Apps!' but then users ask which ones and it gets confusing from there and yada yada...)
However perhaps it does make more sense to think about using Wine for application specific scenarios.
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.
Do we know Canonical's stance on that? That scenario could be consistent and provide real end user benefit sans confusion.
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 don't see them providing packages for proprietary applications. Not for the Ubuntu project, which is completely free (except drivers). Maybe through the Canonical store, which also provides a legal but proprietary DVD player.
Remco
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 :)
On Thu, Dec 11, 2008 at 6:22 PM, Ben Klein shacklein@gmail.com wrote:
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).
Yes the wrapper script is implied by the deb package/template. I think each application package should have a hard dep on a given Wine version and the launcher script should reflect that. Then it would be up to the package maintainer to update his package for newer versions of Wine. If you did it right you could make it compatible across multiple Wine versions and just use the deb/rpm database to check to make sure version numbers are high enough and or blacklist known bad ones.
Its not that hard to keep seperate versions of Wine isolated. You could have something like
/usr/local/lib/wine-1.0.1 /usr/local/lib/wine-1.2.0 etc
And use the variables Wine already supports to point to different Wine binaries and Wineserver versions. CodeWeavers already does this to allow CrossOver and Wine to co-exist on the same system.
As far as the database resources, that information is already there in appdb. Its just a matter of getting it in the right framework to be automagically packaged. Lets say an application is known as gold or whatever in appdb. Assuming a known good version of Wine is listed and the proper dependances are met, it should be possible to automate generation of the packages. Maybe we are talking about some sort of xml importing data exchange tool to generate the deb specs and the Wine templates. I am not sure, I've not really thought the automation part through enough. That can really come later once some proof of concept debs/rpms are built for IE and Photoshop.
I think the first step is to take what we've already got with IE6 in Winetricks. Find a stable version of Wine it works well with and attempt to make a package for it based upon all of the ideas already covered here.
On Fri, Dec 12, 2008 at 11:52 AM, Steven Edwards winehacker@gmail.com wrote:
Lets say an application is known as gold or whatever in appdb. Assuming a known good version of Wine is listed and the proper dependances are met, it should be possible to automate generation of the packages.
I think you have a bit too much faith in the AppDB. If I had a nickel for every times I've seen platinum and gold ratings for apps that had dozens of native dlls or complicated scripts to work around wine bugs, I'd be a much richer man.
I know that this wouldn't be used for a lot of apps, just really popular ones that (assumedly) at least a few developers have used/verified, but worth pointing out nonetheless.
On Fri, Dec 12, 2008 at 1:34 PM, Austin English austinenglish@gmail.com wrote:
I think you have a bit too much faith in the AppDB. If I had a nickel for every times I've seen platinum and gold ratings for apps that had dozens of native dlls or complicated scripts to work around wine bugs, I'd be a much richer man.
I know that this wouldn't be used for a lot of apps, just really popular ones that (assumedly) at least a few developers have used/verified, but worth pointing out nonetheless.
It might be possible to have some sort of certification system setup whereby the maintainer of the appdb entry signs off on the information being correct. I could see a fit for some sort of tool being developed to automate this whole process for apps that are certified but this is thinking too far ahead. When I get some time I'll see if I can put together a proof of concept IE deb package.
Thanks
On Fri, Dec 12, 2008 at 12:59 PM, Steven Edwards winehacker@gmail.com wrote:
On Fri, Dec 12, 2008 at 1:34 PM, Austin English austinenglish@gmail.com wrote:
I think you have a bit too much faith in the AppDB. If I had a nickel for every times I've seen platinum and gold ratings for apps that had dozens of native dlls or complicated scripts to work around wine bugs, I'd be a much richer man.
I know that this wouldn't be used for a lot of apps, just really popular ones that (assumedly) at least a few developers have used/verified, but worth pointing out nonetheless.
It might be possible to have some sort of certification system setup whereby the maintainer of the appdb entry signs off on the information being correct. I could see a fit for some sort of tool being developed to automate this whole process for apps that are certified but this is thinking too far ahead. When I get some time I'll see if I can put together a proof of concept IE deb package.
Many times the maintainers are the ones giving those falsely inflated ratings.
I could see this being useful for really popular apps, and in a small enough number to where a developer or AppDB admin could sign off on it.
On Fri, 12 Dec 2008, Austin English wrote:
If I had a nickel for every times I've seen platinum and gold ratings for apps that had dozens of native dlls or complicated scripts to work around wine bugs, I'd be a much richer man.
What about clarifying the wording on http://appdb.winehq.org/help/?sTopic=maintainer_ratings ?
My suggestion for "Platinum": "Application installs and runs flawlessly completely/at highest settings ‘out of the box‘. No changes required in winecfg." (add "completely/at highest settings")
For "Gold": "Application works completely/at highest settings flawlessly in the latest Wine development release (no patches needed), possibly with DLL overrides, other settings, or third party software." (add same as above; add "latest Wine development release"; remove "*some* DLL overrides)
I feel that games that are playable only at low settings shouldn't get Gold or Platinum ratings at all. Other opinions?
Austin: I think for apps that run completely with tweaks a Gold rating is okay regardless of the number of tweaks involved; for the user it doesn't matter really whether one or ten DLLs have to be overridden. I wouldn't go as far as allowing patched Wine versions though.
I also suggest to hyperlink every mention of "Rating" in the browser with that page. Otherwise it isn't completely clear (without searching) what the individual ratings mean really. Who has the rights to change AppDB on that level?
Regards
I think that Highest Settings is unfair, there are issues with many games in Windows with settings maxed (Check Oblivion forums, every problem we have in wine is also had by people in native windows). Default settings is a far more appropriate measuring stick.
I also think there needs to be a reviewer meta-review system, similar to slashdot's karma system. There are a few reviewers consistently rating 1 or 2 steps above what they should. "Rating: Gold. What doesn't work: Sound. What wasn't tested: Multiplayer." WTF?
2008/12/15 M.Kiesel wine-devel@continuity.cjb.net:
My suggestion for "Platinum": "Application installs and runs flawlessly completely/at highest settings 'out of the box'. No changes required in winecfg." (add "completely/at highest settings")
For "Gold": "Application works completely/at highest settings flawlessly in the latest Wine development release (no patches needed), possibly with DLL overrides, other settings, or third party software." (add same as above; add "latest Wine development release"; remove "*some* DLL overrides)
I feel that games that are playable only at low settings shouldn't get Gold or Platinum ratings at all. Other opinions?
Austin: I think for apps that run completely with tweaks a Gold rating is okay regardless of the number of tweaks involved; for the user it doesn't matter really whether one or ten DLLs have to be overridden. I wouldn't go as far as allowing patched Wine versions though.
I also suggest to hyperlink every mention of "Rating" in the browser with that page. Otherwise it isn't completely clear (without searching) what the individual ratings mean really. Who has the rights to change AppDB on that level?
Regards
2008/12/15 M.Kiesel wine-devel@continuity.cjb.net:
On Fri, 12 Dec 2008, Austin English wrote:
If I had a nickel for every times I've seen platinum and gold ratings for apps that had dozens of native dlls or complicated scripts to work around wine bugs, I'd be a much richer man.
What about clarifying the wording on http://appdb.winehq.org/help/?sTopic=maintainer_ratings ?
My suggestion for "Platinum": "Application installs and runs flawlessly completely/at highest settings 'out of the box'. No changes required in winecfg." (add "completely/at highest settings")
I think it's fine as is. Some games won't run at highest settings on Windows, due to crappy video card, etc.
For "Gold": "Application works completely/at highest settings flawlessly in the latest Wine development release (no patches needed), possibly with DLL overrides, other settings, or third party software." (add same as above; add "latest Wine development release"; remove "*some* DLL overrides)
The ratings are done on a per version basis, so no need to stipulate the latest release. The patches and DLL comments I agree with.
I feel that games that are playable only at low settings shouldn't get Gold or Platinum ratings at all. Other opinions?
Depends on how they run in Windows on the same hardware ;-).
Austin: I think for apps that run completely with tweaks a Gold rating is okay regardless of the number of tweaks involved; for the user it doesn't matter really whether one or ten DLLs have to be overridden. I wouldn't go as far as allowing patched Wine versions though.
I don't disagree with that, though I see it quite a bit when approving programs in the AppDB (though I'm not the one usually doing it, I only go through the queue when I'm on the AppDB for other reasons). The main problem is when it get a _platinum_ rating.
I also suggest to hyperlink every mention of "Rating" in the browser with that page. Otherwise it isn't completely clear (without searching) what the individual ratings mean really.
Agreed.
Who has the rights to change AppDB on that level?
I'll send a patch tomorrow. If you don't see a change within a few days, remind me.
On Mon, 15 Dec 2008 19:28:18 -0600 "Austin English" austinenglish@gmail.com wrote:
2008/12/15 M.Kiesel wine-devel@continuity.cjb.net:
On Fri, 12 Dec 2008, Austin English wrote:
If I had a nickel for every times I've seen platinum and gold ratings for apps that had dozens of native dlls or complicated scripts to work around wine bugs, I'd be a much richer man.
What about clarifying the wording on http://appdb.winehq.org/help/?sTopic=maintainer_ratings ?
I've been thinking about this myself.
My suggestion for "Platinum":
Application runs as well as on Windows "out of the box" (no changes required in winecfg) and has no open, confirmed bugs with a severity higher than enhancement.
My suggestion for "Gold":
Application runs as well as on Windows with some tweaks. Any open, confirmed bugs with a severity higher than "trivial" can be worked around with dll overrides, other settings, or third party software.
My rationale:
1. If an app doesn't run flawlessly on Windows (and how many do?), we shouldn't expect it to run flawlessly in Wine. 2. With complex apps like Word or Photoshop, testers often test only the basic functions, and give a gold or platinum rating based solely on that. Word 2003 currently has 19 bugs linked to it, of which 11 are confirmed, but someone who tested only basic word processing functions could legitimately give it a platinum rating under the current guidelines. We can't force people to test everything, but we can at least limit the top ratings based on known bugs.
Rosanne DiMesio dimesio@earthlink.net
Mentioning bug severity levels in appdb submission rules is asking for trouble. Most appdb users don't use bugzilla at all.
2008/12/16 Rosanne DiMesio dimesio@earthlink.net:
On Mon, 15 Dec 2008 19:28:18 -0600 "Austin English" austinenglish@gmail.com wrote:
2008/12/15 M.Kiesel wine-devel@continuity.cjb.net:
On Fri, 12 Dec 2008, Austin English wrote:
If I had a nickel for every times I've seen platinum and gold ratings for apps that had dozens of native dlls or complicated scripts to work around wine bugs, I'd be a much richer man.
What about clarifying the wording on http://appdb.winehq.org/help/?sTopic=maintainer_ratings ?
I've been thinking about this myself.
My suggestion for "Platinum":
Application runs as well as on Windows "out of the box" (no changes required in winecfg) and has no open, confirmed bugs with a severity higher than enhancement.
My suggestion for "Gold":
Application runs as well as on Windows with some tweaks. Any open, confirmed bugs with a severity higher than "trivial" can be worked around with dll overrides, other settings, or third party software.
My rationale:
- If an app doesn't run flawlessly on Windows (and how many do?), we shouldn't expect it to run flawlessly in Wine.
- With complex apps like Word or Photoshop, testers often test only the basic functions, and give a gold or platinum rating based solely on that. Word 2003 currently has 19 bugs linked to it, of which 11 are confirmed, but someone who tested only basic word processing functions could legitimately give it a platinum rating under the current guidelines. We can't force people to test everything, but we can at least limit the top ratings based on known bugs.
Rosanne DiMesio dimesio@earthlink.net
On Mon, Dec 15, 2008 at 10:56 PM, Ben Klein shacklein@gmail.com wrote:
Mentioning bug severity levels in appdb submission rules is asking for trouble. Most appdb users don't use bugzilla at all.
Agreed.
Please bottom post on Wine mailing lists.
2008/12/16 Rosanne DiMesio dimesio@earthlink.net:
On Mon, 15 Dec 2008 19:28:18 -0600 "Austin English" austinenglish@gmail.com wrote:
2008/12/15 M.Kiesel wine-devel@continuity.cjb.net:
On Fri, 12 Dec 2008, Austin English wrote:
If I had a nickel for every times I've seen platinum and gold ratings for apps that had dozens of native dlls or complicated scripts to work around wine bugs, I'd be a much richer man.
What about clarifying the wording on http://appdb.winehq.org/help/?sTopic=maintainer_ratings ?
I've been thinking about this myself.
My suggestion for "Platinum":
Application runs as well as on Windows "out of the box" (no changes required in winecfg) and has no open, confirmed bugs with a severity higher than enhancement.
My suggestion for "Gold":
Application runs as well as on Windows with some tweaks. Any open, confirmed bugs with a severity higher than "trivial" can be worked around with dll overrides, other settings, or third party software.
My rationale:
- If an app doesn't run flawlessly on Windows (and how many do?), we shouldn't expect it to run flawlessly in Wine.
- With complex apps like Word or Photoshop, testers often test only the basic functions, and give a gold or platinum rating based solely on that. Word 2003 currently has 19 bugs linked to it, of which 11 are confirmed, but someone who tested only basic word processing functions could legitimately give it a platinum rating under the current guidelines. We can't force people to test everything, but we can at least limit the top ratings based on known bugs.
I like the 'runs as well as on Windows' bit... Much better metric, and accounts for hardware differences, etc.
On Mon, 15 Dec 2008, Austin English wrote:
What about clarifying the wording on http://appdb.winehq.org/help/?sTopic=maintainer_ratings ? My suggestion for "Platinum": "Application installs and runs flawlessly completely/at highest settings 'out of the box'. No changes required in winecfg." (add "completely/at highest settings")
I think it's fine as is. Some games won't run at highest settings on Windows, due to crappy video card, etc.
Good point. I was thinking about games that run fine in Windows at highest settings but do not in Wine (on the same machine). What about "Application installs and runs just as it does in Windows, without <b>any</b> custom Wine tweaks or settings."?
There's still a 'loophole' with for example hardware that works fine in Windows but doesn't in *nix (ATI graphics cards...) but probably it's no good to add tons of fine print to that definition.
For "Gold": "Application works completely/at highest settings flawlessly in the latest Wine development release (no patches needed), possibly with DLL overrides, other settings, or third party software." (add same as above; add "latest Wine development release"; remove "*some* DLL overrides)
The ratings are done on a per version basis, so no need to stipulate the latest release. The patches and DLL comments I agree with.
"Application works just as it does in Windows with unpatched Wine, possibly with DLL overrides, other settings, or third party software."?
[Patched Wine versions and Gold rating]
I see it quite a bit when approving programs in the AppDB (though I'm not the one usually doing it, I only go through the queue when I'm on the AppDB for other reasons). The main problem is when it get a _platinum_ rating.
I agree. Still, I feel that Gold should mean "an average user should be able to get the game running completely", and while with winetricks etc. adding DLL overrides is no problem, patching/building Wine probably IS. Also this might be an incentive to get patches into Wine proper instead of leaving hacks in AppDB/Bugzilla ("Well, the game is gold now, no need to fix things further"). Not sure whether I'm realistic here though ;-).
I also suggest to hyperlink every mention of "Rating" in the browser with that page. Otherwise it isn't completely clear (without searching) what the individual ratings mean really.
[...]
Who has the rights to change AppDB on that level?
I'll send a patch tomorrow. If you don't see a change within a few days, remind me.
Cool, thanks a lot!
Regards
2008/12/13 Steven Edwards winehacker@gmail.com:
On Thu, Dec 11, 2008 at 6:22 PM, Ben Klein shacklein@gmail.com wrote: Yes the wrapper script is implied by the deb package/template. I think each application package should have a hard dep on a given Wine version and the launcher script should reflect that. Then it would be up to the package maintainer to update his package for newer versions of Wine. If you did it right you could make it compatible across multiple Wine versions and just use the deb/rpm database to check to make sure version numbers are high enough and or blacklist known bad ones.
If you did it wrong, you could end up with one copy of Wine per application, and have overlap in application support (e.g. foo works in 1.0.1 and 1.1.10, but has a hard dep on 1.0.1, bar has hard dep on 1.1.10).
Its not that hard to keep seperate versions of Wine isolated. You could have something like
/usr/local/lib/wine-1.0.1 /usr/local/lib/wine-1.2.0 etc
And use the variables Wine already supports to point to different Wine binaries and Wineserver versions. CodeWeavers already does this to allow CrossOver and Wine to co-exist on the same system.
I did this sort of thing myself with a wrapper script I called vineyard. I never made a big deal of it because: 1) Putting multiple versions of wine in /usr/local/wine* or /usr/wine* is ugly 2) Ideally, we don't need to have multiple concurrent Wine versions, and if I found out what apps I used to run using vineyard, I'd likely find that I only need 1.1.10 to run them all now (I know for a fact that one of them works reasonably well now)
As far as the database resources, that information is already there in appdb.
It's already been said before, but appdb can be hideously inaccurate.
Its just a matter of getting it in the right framework to be automagically packaged. Lets say an application is known as gold or whatever in appdb. Assuming a known good version of Wine is listed and the proper dependances are met, it should be possible to automate generation of the packages.
I would object to any system like what is being proposed here that doesn't have a full version compatibility database attached and some algorithm to calculate the minimum set required for your applications. Perhaps automagic appdb info would be a good start, but have the system prefer certified data by trusted testers.
The biggest problem with maintaining a compatibility database is the manpower and resources required. Every time a new version of the application comes out, full range of Wine version testing would be required for a quality database. Even the idea of certifying specific appdb entries will take a lot of resources and manpower.
I think the first step is to take what we've already got with IE6 in Winetricks. Find a stable version of Wine it works well with and attempt to make a package for it based upon all of the ideas already covered here.
I just thought - it's not just a problem of maintaining concurrent Wines on end-user systems, it's also a problem of maintaining concurrent Wine versions in the central repositories. You wouldn't be able to use the current Wine packages because they install in /usr/, not in /usr/wine-version. And unless you do something like directly accessing older archives and manually installing (so that it's outside high-level package management), each version of Wine in the repository would need its own package *name*!
This all sounds like a lot of work to me, but if people are willing to put in the time and effort to do it *properly*, it does have its merits. But I have to ask, what exactly is this system going to replace?
Current equivalent method is: 1) Try your app with Wine 2) If it doesn't work, check appdb for Wine version compatibility 3) Follow any instructions on the appdb page, such as reg settings/hacks, DLL overrides, specific Wine versions 4) If it works, yay for you
This proposal of packages for proprietary Windows software follows these steps, then adds a step 5) Create a package based on what you've found that automates step 3. I argue that a more correct way to deal with this is education of newbies.
Am 13.12.2008 um 01:12 schrieb Ben Klein:
But I have to ask, what exactly is this system going to replace?
Current equivalent method is:
- Try your app with Wine
- If it doesn't work, check appdb for Wine version compatibility
- Follow any instructions on the appdb page, such as reg
settings/hacks, DLL overrides, specific Wine versions 4) If it works, yay for you
This proposal of packages for proprietary Windows software follows these steps, then adds a step 5) Create a package based on what you've found that automates step 3. I argue that a more correct way to deal with this is education of newbies.
As far as I followed the discussion, you'd replace 1) to 3). The one simple rule you'd have to teach people is "Before installing Windows software, install the appropriate compatibility package". Alternatively, if you want to have something like a default Wine package, teach them: "If your app doesn't work, look for a compatibility package".
IMHO, the former is the better, because it's more consistent. You could name the packages like "Wine for Adobe applications" to avoid thousands of new packages. Also, "doesn't work" is a weak description, as non-working features might not be noticed by the user immediately. Third, it's likely tricky to replace Wine with a different version of Wine with the app already installed along other apps on a drive_c.
BTW, how would you interact between different Windows apps running on different versions of Wine?
MarKus
- - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
On Wed, Dec 10, 2008 at 3:42 PM, Zachary Goldberg zgold@bluesata.com wrote:
I agree with Canonical that perhaps it doesn't make sense to make a Winebuntu or a new Ubuntu with Wine as a bigger focus for exactly that reason, it doesn't work for everything and that isn't a great experience. (Anything thats inconsistent is bad for something like Ubuntu. We love Wine but fact is fact, it isn't univerally perfect so they can't advertise 'Full Windows Application Support!' etc. etc. They could advertise 'Will Work with Some Windows Apps!' but then users ask which ones and it gets confusing from there and yada yada...)
However perhaps it does make more sense to think about using Wine for application specific scenarios.
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.
There are a few key pieces missing for this to work
well for the end user though.
1. Wine Prefix Management
Alexandre and I have discussed this a bit and it needs to be well thought out. I'm partial to having
something like
~/.wineprefixes for the private prefixes
and
/usr/local/wineprefixes for the global prefixes
Alexandre likes the idea of having a winelib tool that can do this, and I think thats a great idea. Unfortunately the tool I wrote is GTK+. Also I believe we might need to add some enhancements to libwines support for detecting and maintaining the wineprefix variable, perhaps adding a function for handling the prefixes folder. I've got something like this in the Bordeaux cellar manager.
Also when dealing with things like deb/rpm packages the prefix manager will need to know how to handle these.
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.
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.
4. Most of the backend to support this is already in place. Now that my IE6 changes are in winetricks, I could TODAY create a ie6.deb package. Thanks to other users that have made winetricks steps in the appdb we could do this for a host of other packages.
5. Finally if Cannonical won't host the application debs directly we need to see if Scott will do it or have someone else host them.
Thanks Steven
2008/12/11 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
...
- 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.
The PlayOnLinux (http://www.playonlinux.com) team have install scripts for various applications. I don't know how good these are or how reliable they are.
- Most of the backend to support this is already in place. Now that
my IE6 changes are in winetricks, I could TODAY create a ie6.deb package. Thanks to other users that have made winetricks steps in the appdb we could do this for a host of other packages.
It would be useful to have winetricks distributed in a deb/rpm package, so that you could install it easily to have it updated/managed by the package manager. This would provide the core support for installing applications run on wine via deb/rpm packages (that would depend on winetricks and wine).
Each application would then use winetricks (and any support scripts that it provides, similar to what PlayOnLinux does), and support an install.sh and uninstall.sh script. These scripts can then be run via the pre/post install/uninstall hooks in the deb/rpm packages to do the installation.
For the install.sh and uninstall.sh scripts, it could be useful to provide a mechanism in AppDB to create and modify these so that the maintainers/users of the application could create these scripts. There would need to be a way to aggregate the scripts and to version control them.
Also, to simplify package creation we could have a configuration file that then generates the deb or rpm data and builds the corresponding package output using the package manager tools. This information (and what version of wine the app works well on) could even be extracted from AppDB itself and thus remove the need to have a wine-specific package configuration format.
- Reece
It would be useful to have winetricks distributed in a deb/rpm package, so that you could install it easily to have it updated/managed by the package manager. This would provide the core support for installing applications run on wine via deb/rpm packages (that would depend on winetricks and wine).
Just for the record, the SUSE rpms contain the newest winetricks ;)
Ciao, Marcus
-
Austin English -
Ben Klein -
Dan Kegel -
Kai Blin -
M.Kiesel -
Marcus Meissner -
Markus Hitter -
Reece Dunn -
Remco -
Rosanne DiMesio -
Sparr -
Steven Edwards -
Steven Edwards -
Zachary Goldberg