[pkg-wine-party] Bug#852494: wine: Add libwine.so and libwine.so.1 alternatives

[Jens Reyer]

Hi Javier and Mike,


On 06/17/2017 11:16 PM, Michael Gilbert wrote:
> control: tag -1 moreinfo
> 
>> Please add a libwine.so.1 alternative to libwine packages, and
>> libwine.so to libwine-dev ones.
> 
> There are no reverse dependencies of libwine, so it is not clear to me
> how this would actually be helpful.  Do you have a specific problem
> where it would be, if so what is it?

AFAIK Javier needs it for lmms.


On 01/24/2017 11:15 PM, Javier Serrano Polo wrote:
> The alternatives should not be slaves in the wine package. I suggest to
> move the slave alternatives from wine package to their respective
> packages (wine32-tools and such), and to depend on an
> update-wine-alternatives script (in libwine) that runs
> update-alternatives for the installed packages.

I'm not sure if you suggest to make libwine (instead of wine) the
alternatives-master for all Wine packages - I think that wouldn't work,
because each arch has its own libwine, so we'd have multiple master.
Feel free to prove me wrong.

Alternatively you might ask for the libwine-alternatives to be separate
from the other Wine-alternatives - I don't feel comfortable about having
main Wine and libwine potentially pointing to different Wine versions.

So why not make libwine a slave of wine and let it recommend wine, like
I did for the other packages?  AFAIK "recommends" are not installed for
build-dependencies, so you'd need to explicitly build-depend on wine in
lmms - but imo that's acceptable.  Of course you would have wine, and
wine32 or wine64 (or both if e.g. i386 is available on the build-daemon)
installed unnecessarily then - but their installed size is very small
compared to libwine (and its dependencies).  The only real drawback I
can think of is having potentially unwanted Wine binaries on PATH.
Still, that's what I'd suggest.

Having said all this, I have no experience with packaging system
libraries.  Can we just stay with soversion .0, or do we have to check
if the Wine API changes (sounds strange since Wine is supposed to
provide a stable (!?) Windows API)?  What do others think?

Greets
jre