docu update

[Ivan]

> Anyway, Wine doesn't have any menu
> integration.
And why shouldn't we have the wine programs in the menu?

> Compiling it as i586 or i686 should be fine, very few people use
> processors old enough to barf on it
Sure.

> That's what apbuild solves. It lets you compile for glibc 2.2 on a 2.3
> system, amongst other things.
And what if the user wants a glibc 2.3 build?

> 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.
Maybe, but for example Mandrake users won't get wine listed in the "remove
software" utility, and that will be confusing

> 1.0 implies API stability, not that it's suddenly good enough that
> people won't want to upgrade.
I presume by then wine won't change so quickly. And the average user (the
average pc user, not the average linux geek)
is lazy and often doesn't upgrade if he doesn't have to

> That's entirely wrong, it works fine. What did you think the recent
> high-gig mmap patches were for?
they won't help wine-20040615 any more.

> 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.
That was a benchmark done by comparing Red Hat and Mandrake, it was a few months
ago.

> 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.
> would be somewhat suboptimal as we sacrifice speed for flexibility and distro
neutrality.
Do we NEED to sacrifice such things? Also we can't use it until version 1.0, it
will be reasonable to look at this then.

Ivan.