WineLib Application

[Oleg Lyamtsev]

Hi ALL,

I've made WineLib applicatiion with COM support.
The first problem is: when I try to call Release() method for interfaces, I
have unhandled exception. But I have to clean memory by myself! It seems to
me that WineLib Releases all interfaces before me.
The second problem: How can I package my application to install it on
another computer? Can I avoid Wine installation on that computer?

Thanks,
   Oleg Lyamtsev.

[Mike Hearn]

> The second problem: How can I package my application to install it on
> another computer? Can I avoid Wine installation on that computer?

AFAIK at the moment yes, you need to either install Wine or basically
ship your own version with the application. You can probably use RPM/DEB
for that at the moment, hopefully something better will come along in
the next year or so
> Thanks,
>    Oleg Lyamtsev.

[Dan Kegel]

Mike Hearn wrote:
> > The second problem: How can I package my application to install it on
> > another computer? Can I avoid Wine installation on that computer?
>
> AFAIK at the moment yes, you need to either install Wine or basically
> ship your own version with the application. You can probably use RPM/DEB
> for that at the moment, hopefully something better will come along in
> the next year or so

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 :-)

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.

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

WineLib Application (LSB compatability)

[Mike Hearn]

> 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