docu update

[Mike Hearn]

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