Bringing Wine into Main

Scott Ritchie scott at open-vote.org
Mon Dec 15 10:22:58 GMT 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

After some discussion with a few core devs at UDS, I feel it is time to
formally propose that Wine be moved into main.  Popcon says 10% of our
users have Wine installed already, and this is only the case today: we
don't even count Wubi installs, and some fraction of the 2 billion
Windows users would switch if we made Wine easier.

Wine is popular because it's valuable to users; when Dell announced a
line of Ubuntu-powered machines, the fact that they didn't include Wine
made a few news headlines.  Wine wasn't ready at the time, however it is
rapidly improving.  The question of how to include Wine is a pragmatic
one, especially if Canonical eventually offers support.

Obviously, no one could support every Windows application in existence;
indeed, with closed source applications we wouldn't even want to.  This
makes Windows applications similar to proprietary drivers in Ubuntu: we
make it easy for users who need them, but users who need complete
support must look elsewhere.

A good model to follow is the one used for desktop effects in Feisty.
We presented them to the user as a sort of technology demo, disabled by
default, but available to those who wanted to try it.  The warnings were
clear, and users weren't given grand expectations.  Once enough bugs
were worked out in later releases, desktop effects became an integral
part of the distribution.

There are other benefits to being the first distro to feature Wine in a
prominent way (Corel doesn't count).  Most Windows applications actually
function now, and virtually all will at least install.  There are some
important exceptions, but even a small amount of Windows compatibility
is an excellent feature for Ubuntu. As Jono said at the beginning of
UDS: we can do what others do, or we can win.

Moving Wine into Main (or whatever becomes of main with the archive
reorganization) will require a fair amount of work.  Most of Wine's
dependencies are already in main, but on amd64 Wine still requires
ia32-libs for about 15 packages that don't have separate lib32 versions.

I'd like to work on Wine in Ubuntu full time, however as a first step to
keep me busy I could easily spend a few months modifying these packages
to work properly in 32 bit mode on amd64.  This is work that will have
to be done eventually anyway, as 32 bit Windows applications are going
to be around for a long time.  The other option, shoving Wine into a
32-bit chroot, will be obsolete within a year or so as Wine adds support
for 64 bit applications.

Once the ground work is done there are a lot of UI elements to Wine that
will need to be written and incorporated upstream.  Chief among these is
our program for handling double-clicking on an executable when Wine
itself isn't installed, which I myself will create.  Wine upstream
meanwhile has agreed to implement other backend changes needed for
further UI enhancements that will need to be written, such as being able
to change the windows version emulated by right clicking a program and
selecting properties.

A partial list of the major Gnome-Wine integration tasks I'd work on is
on my wiki page: https://wiki.ubuntu.com/ScottRitchie - KDE versions are
also a possibility as well, although community help for them will be needed.

There's also great potential to build upon Wine as a platform for
porting applications.  In theory, there's nothing stopping us from using
Wine as a means of creating a package out of an arbitrary piece of
formerly Windows-only software; Google has already done this in-house
for Picassa, however we could take it one step further and package
everything from the open source eMule to commercial tax software.  With
proper packages, these programs would be easier to install and use on
Ubuntu than in Windows itself.

There are many other small issues to worry about as Wine becomes a more
fully integrated part of the system, however I wanted to bring the idea
forward now to get some feedback and explain what I'd like to work on
for Jaunty and beyond.

Thanks,
Scott Ritchie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklGL/kACgkQWEAwJjh+4mMFTwCfaOuQcG++lWPDtv/ywy4hr0gH
bAgAn2a/rEsoXvou2+R8rAaCOYw2pUUD
=9cmk
-----END PGP SIGNATURE-----



More information about the ubuntu-devel mailing list