WineLib Application (LSB compatability)

Mike Hearn m.hearn at signal.qinetiq.com
Mon Mar 3 10:48:05 CST 2003


> I should point out that Mike is working on something meant to replace RPM
> and DEB packages, which is why he delivered that glancing insult at them :-)

lol, well our stuff won't be ready for a while yet, and I didn't mean
for it to be an insult. As it says on the FAQ on our site, we're not
intending to replace RPM or DEB, far from it.

Anyway, there's not much intrinsically wrong with RPM or DEB themselves,
the main problem is that you have to make them for each distro, although
source rpms can be fairly neutral (ignoring dependancy naming etc) you
still have to tweak them for particular distros usually, which is rather
sucky. That's more a Linux-wide problem though rather than an issue with
those particular packaging systems.

> There's also the LSB package, which solves all dependency problems
> by requiring the package to be linked statically with anything it needs
> that's not defined by the LSB.  I rather like this, but Mike hates it.

It's interesting, I was just talking to Doug Beattie about this very
issue, he picked up on a mail I sent to the CrossOver list and suggested
maybe Wine could become LSB compliant. That's certainly a good long term
goal (and i've considered working on it myself) but yeah, statically
linking everything is a super-ugly solution :( Maybe it'd work OK for
Wine, I'm not entirely sure how many dependancies it has, but I'm not
sure it's many more than what the LSB standardises.

Given the current threading problems, I kind of suspect the LSB can only
solve some of the problems related to portability of Wine on Linux.

> Now that distributions are becoming LSB-compliant, it's time for people
> to consider packaging their apps as LSB packages, I think.  When and if
> Mike's effort becomes "Son-of-LSB-package", it will just reduce the
> bloat associated with static linking, I think.

There are a whole load of issues that need to be addressed really, the
static linking thing is only one of them. At some point this week I'm
going to try and get the new packaging group underway, focussed at first
simply on improving the LSB RPM system so it can have dependancies.
Anyway, that's a bit OT.

It'd be good to have an LSB package of Wine available, that'd certainly
ease the burden of packaging. You'd still need at least two for the
different glibc versions though, I don't think there's any way around
that until the transition to the new glibc is over :( Maybe Alexandre
can work some magic so that one binary of Wine can deal with both,
that'd be pretty good, but I think the answer is it'd be a compile-time
thing.

thanks -mike

-- 
Mike Hearn <m.hearn at signal.qinetiq.com>
QinetiQ - Malvern Technology Center




More information about the wine-devel mailing list