docu update

[Mike Hearn]

On Sun, 2004-06-20 at 01:02 +0200, Ivan wrote:
> And why shouldn't we have the wine programs in the menu?

We should but that's not a packaging problem, that's a matter of waiting
for XDG menus to become prevalent then teaching wineshelllink how to use
libxslt and apply transforms to the menu definitions, ie it's a matter
of code not packaging.

> And what if the user wants a glibc 2.3 build?

It makes no difference. The features that are implicitly used in glibc
2.3 aren't important for desktop apps.

> Maybe, but for example Mandrake users won't get wine listed in the "remove
> software" utility, and that will be confusing

CrossOver has its own menu integration. Yes removing software might be
confusing but IIRC the "remove software" utility is just a list of
packages installed which is by definition confusing as you have binutils
listed in with kdevelop and whatnot. Solving that problem is a desktop
issue, I've done a bit of work on it but nothing has got into mainstream
yet.

> 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

I don't see why it'd slow down after we freeze libwine, it's not that
many functions...

> they won't help wine-20040615 any more.

So the user has to upgrade ... and ?

> That was a benchmark done by comparing Red Hat and Mandrake, it was a few months
> ago.

So it could have been anything, in other words. I'd need to see hard
figures in a controlled environment.

> 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.

That's not talking about the binaries, that's talking about the package
format itself. And for apps like Wine it doesn't matter, that FAQ entry
is saying why it'd be bad idea to install 1000 of them at once as is
typical for a first time distro install.

thanks -mike