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.