Mike Hearn wrote:
can't we package Wine as an LSB package?
No, that's really not possible/sensible.
I suspect Wine depends on nothing that isn't in the LSB.
I suspect it depends on a lot, for instance FreeType, OpenSSL, CUPS, fontconfig, libasound/arts/jack, SANE, libjpeg etc etc.
LSB 2.0 doesn't deal with sound, scanning, or printing (beyond lpr, anyway?), so an LSB 2.0 version of Wine would probably have to do without those. That'd be fine for me - I never use any of those features - but I realize that real users require themm.
LSB 3, on the other hand, is going to add Gnome support, so they're at least thinking about the desktop now. (Your other objections - FreeType, fontconfig, libjpeg, OpenSSL, etc - could be packaged along with an LSB implementation of Wine, so they're not really an issue.)
It would be worth doing an LSB 2.0 implementation of Wine as a demonstration of what's missing in the LSB; IMHO it would help put pressure on the LSB folks to include the missing bits in the next version.
But remember, LSB can only standardize what has already stabilized in the field, and things like sound and printing are only now starting to not suck on Linux... - Dan
On Sat, 20 Nov 2004 17:09:18 -0800, Dan Kegel wrote:
LSB 2.0 doesn't deal with sound, scanning, or printing (beyond lpr, anyway?),
It really doesn't deal with anything useful at all that isn't already stable and on every Linux system anyway.
so an LSB 2.0 version of Wine would probably have to do without those.
Those were just random examples, there are many more. An LSB 2 version of Wine would be seriously crippled next to a non-LSB version.
LSB 3, on the other hand, is going to add Gnome support,
Possibly. They've been saying they were going to be adding desktop support for years. The LSB process moves so slowly though that there's no chance of them ever having an up to date desktop specification. GNOME releases on a 6 month release cycle, GTK is more like 9 months but these are all less than a year. Are people going to hold back depending on new APIs because it's not in the LSB yet? No, there's no evidence of that at all.
They also said they were going to add C++ support to LSB 2 - didn't happen, except as an optional "module" that Red Hat aren't going to implement anyway. Why? Because the gcc team decided stability right now would hurt their engineering goals and Red Hat employee a lot of the gcc team. In other words the primary distro developers support the LSB when it's convenient to do so, and don't when it isn't.
so they're at least thinking about the desktop now. (Your other objections - FreeType, fontconfig, libjpeg, OpenSSL, etc - could be packaged along with an LSB implementation of Wine, so they're not really an issue.)
That would be a bad idea. Statically linking FreeType would stop people who have switched on the TrueType bytecode interpreter from using it (some people do have licenses), OpenSSL has a very poor track record for needing security updates and wasn't libjpeg found to be vulnerable to buffer overflows lately? Some things it just makes no sense to statically link like libasound as it communicates directly with kernel interfaces that may not be stable.
Dynamic linking exists for a reason, we should use it. The fact that the LSB is apparently constitutionally unable to meet our needs shouldn't mean turning our back on dynamic linking. It should mean either fixing the LSB or using something else.
It would be worth doing an LSB 2.0 implementation of Wine as a demonstration of what's missing in the LSB; IMHO it would help put pressure on the LSB folks to include the missing bits in the next version.
About a year ago (maybe more) I tried to do an LSB compile of DBUS and failed miserably. Not only was the LSB build environment buggy but it would have implied producing a bloated and crippled version. These days it'd be even worse, ie no SELinux support.
I really don't think an LSB build of Wine would be easy or productive.
As for putting pressing on the LSB folks, I don't think they care about us. They seem to care more about ISO certification, witness the mess produced from trying to get the gcc team to make a stable C++ ABI to meet ISO deadlines.
But remember, LSB can only standardize what has already stabilized in the field, and things like sound and printing are only now starting to not suck on Linux...
That's one of the problems with it. The LSB is toothless while upstream projects continue to treat platform stability as a trivial detail. Note: the LSB did nothing to avoid the NPTL fiasco and it's doing nothing to avoid the COMPOSITE ARGB mess despite both libc and Xlibs being a part of the supposedly "stable" base.
Other problems involve the fact that it has no traction at all with popular distros - out of the box big-name distros aren't compliant eg Slackware (no PAM), Fedora (no LSB package installed by default), Gentoo (standards compliance difficult on this distro anyway due to its level of configurability) etc. In fact I'm not aware of any distros at all that are actually LSB compliant out of the box, even though most of them could be with minimal work. You usually have to install extra packages, and even then the guarantees provided by the LSB are minimal.
The backwards compatibility breaks that actually matter to people (because they break their software) have never even been raised by the LSB team.
This shouldn't be surprising. There's little they can do, unlike Microsoft they can't fire maintainers who make breaking changes.
Believe me. I've looked into the LSB extensively as part of working on autopackage, posted to their lists, even developed easier to use (if less provable) equivalents of their tools and come to the conclusion that the LSB isn't a solution, it's a symptom.
thanks -mike
LSB 3, on the other hand, is going to add Gnome support, so they're at least thinking about the desktop now. (Your other objections - FreeType, fontconfig, libjpeg, OpenSSL, etc - could be packaged along with an LSB implementation of Wine, so they're not really an issue.)
Forgive the slight shift to off topic, but a while back, I asked the LSB if they'd consider adding Wine to the app-battery (standard tests required for LSB certification).
They were actually quite open to the notion; Alexandre was working with someone technical on the challenges involved.
Candidly, I dropped the ball (got too busy :-( ), but if someone else was willing to work that through, boy would that be nice.
Cheers,
Jer
Jeremy White wrote:
... a while back, I asked the LSB if they'd consider adding Wine to the app-battery (standard tests required for LSB certification).
They were actually quite open to the notion; Alexandre was working with someone technical on the challenges involved.
Candidly, I dropped the ball (got too busy :-( ), but if someone else was willing to work that through, boy would that be nice.
Sounds like a good idea; maybe sometime between 0.9 and 1.0 would be the right time... no point in doing it while Wine is still changing so quickly, IMHO. - Dan
-
Dan Kegel -
Jeremy White -
Mike Hearn