Canonical and wine

Ben Klein shacklein at
Fri Dec 12 18:12:06 CST 2008

2008/12/13 Steven Edwards <winehacker at>:
> On Thu, Dec 11, 2008 at 6:22 PM, Ben Klein <shacklein at> 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

> 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

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.

More information about the wine-devel mailing list