(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.
Ivan.
On Sun, 2004-06-20 at 00:12 +0200, Ivan wrote:
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.
No, that's what autopackage is designed to deal with. It has abstraction code for the menu systems. Anyway, Wine doesn't have any menu integration. The only thing we expose to the desktop is winecfg which doesn't work yet so for now the point is somewhat academic.
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.
Compiling it as i586 or i686 should be fine, very few people use processors old enough to barf on it, and if they do I really doubt it makes much difference anyway. That sort of optimization is fine when you've eliminated the algorithmic bottlenecks which we are a long way off from doing.
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,
That's what apbuild solves. It lets you compile for glibc 2.2 on a 2.3 system, amongst other things.
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).
Yes, we still do that, but most people use the Loki installer - in fact I'm pretty sure it's the most popular by a long way.
Now, if wine was shipped on a CD (Could be done for 1.0 that won't change for some time),
1.0 implies API stability, not that it's suddenly good enough that people won't want to upgrade.
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
I suggest you do the amount of research into binary portability I have before making such statements. I can assure you this is possible.
Anyway a moments thought would reveal that it *is* possible, as this is exactly what CodeWeavers do. RPM vs DEB vs Loki setup makes no difference, they are exactly the same binaries inside.
, for example wine currently doesn't work on FC2 at all,
That's entirely wrong, it works fine. What did you think the recent high-gig mmap patches were for?
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)?
Just build them for i586 or i686, like I said, that should work just fine. I really doubt anybody is running Wine on a system that can't cope with an i586 compiled binary. 30% sounds extremely high anyway, I'd want to see hard figures on that.
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.
Actually, yes it is. Go read the docs on autopackage.org to find out how. Portable binaries are a good thing and are going to become common place, in fact for 3rd party software like Wine I suspect they'll become dominant in future.
thanks -mike
-
Ivan -
Mike Hearn