Canonical and wine

Steven Edwards winehacker at gmail.com
Fri Dec 12 11:52:43 CST 2008


On Thu, Dec 11, 2008 at 6:22 PM, Ben Klein <shacklein at 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.

-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo



More information about the wine-devel mailing list