docu update

Ivan puoti at
Sat Jun 19 17:12:33 CDT 2004

> (a) and (b) can be solved by WineHQ providing its own distro-neutral, run
> anywhere binary packages.
This isn't easy to do, and it means you have to A) Leave out some features (mime
types, menus, that most distros handle in a different way) or B) package
menu/mime stuff for all distros, meaning the user downloads a big binary but
will only need part of it. Also, it means we have it compiled for only one
architecture. But not all distros use the same one. For example, all software on
Mandrake linux is built for i586, and I don't see why that should change. Also
how can you have one binary work on platforms that are so different? For
example, some users will still use (and want to use) systems that use glibc 2.2,
so what do you do, ship 2 binaries for the different versions of glibc? Also,
lots of users like to install software using the native packaging system of
their distro, infect CodeWeavers now provides native Debs and RPMs of crossover,
or at least it did at some point (Not sure if this is still true). Now, if wine
was shipped on a CD (Could be done for 1.0 that won't change for some time), we
could just have an installer that detected the distro, and installed the
appropriate files, but if users have to download (Remember many users still use
56k modems, and that will stay true for quite some time) they only want to have
what they really need. I think we won't be able to have a single binary that
works on all distros, they are all just to different, for example wine currently
doesn't work on FC2 at all, but works perfectly on other distros. Also some
distros are built for i386, others for i586 and others for i686, how can you
have one binary for all, force them to all use i386 (That will be about 30%
slower that a i586 build)? Sure, it may be possible to build one binary and run
it anywhere, but in most cases it wouldn't run as well (and as fast) as a build
done natively on the distro.


More information about the wine-devel mailing list