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.
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
-
Ivan -
Mike Hearn