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

Jens Reyer jre.winesim at gmail.com
Wed Jan 17 14:48:13 UTC 2018


On 01/10/2018 09:07 PM, Javier Serrano Polo wrote:
> El dc 10 de 01 de 2018 a les 19:51 +0100, Jens Reyer va escriure:
>> 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.
> 
> Then make libwine depend on a wine-alternatives package that ships the
> update-wine-alternatives script.

No, then we'd have no master at all (or did I miss something?).  The
"update-wine-alternatives script" is in 3 files
(debian/wineVERSION.{postinst,prerm,triggers}).  It's core is:

  update-alternatives --quiet \
    --install /usr/bin/wine wine /usr/bin/wineDEBSUFFIX $PRIORITY \
              $slaves

The second line is about the master, we always need it.  And I want the
master to be "wine", not "libwine.so.0" (e.g. master's name is used in
the user interfacing command "update-alternatives --config wine").  So I
still see no alternative to using wine(-development) for the
alternatives scripts, and using /usr/bin/wine as master.



Now, unfortunately there's also another thing I missed here: upstream
does not consider libwine to be a general-purpose library. We discussed
that because they call exit in this shared library:

https://www.winehq.org/pipermail/wine-devel/2016-October/114992.html
"The reason for this is that libwine is not like other libraries where
Debian's check may make sense.  It's not a general-purpose library.
It's only really useful for Wine itself and for a program which wants to
be an alternative Wine loader.  The client of libwine will want it to
call exit() when needed."

I should have thought about this earlier, but imo this shows that making
libwine public is wrong.
If lmms-vst-server handles the use of exit in libwine well, I think it's
ok to use rpath to link to the private lib.


To sum up, these are the issues:
- upstream considers libwine to not be a general-purpose library
- I'm not sure how stable its api is
- Imo we should stay with pkg:wine(-development) providing the
  master /usr/bin/wine


Any other opinion? Close this bug?


Greets
jre



More information about the pkg-wine-party mailing list