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/