Bug#852494: wine: Add libwine.so and libwine.so.1 alternatives
On 20.05.2018 02:20, Javier Serrano Polo wrote: > El ds 19 de 05 de 2018 a les 23:39 +0200, Jens Reyer va escriure: >> I definitely want the well-established system command >> "update-alternatives" to be used. > > What are the requirements? > "update-alternatives --config wine" must work if wine or wine- > development are installed. Only this one? This one definitely yes. And the state of either solution must be in sync with the other (so if I have e.g. "wine" installed, but use your solution, the states must match. And vice versa.) I can't give you a complete list a priori, that's not possible. It depends on the way you choose to implement it. Please don't see this as an excuse I give now to weasel out later on, I'm really interested in getting this issue solved. Please assume good faith. We have to keep in mind that libwine would be a public library then, so symbols need to be handled accordingly then. It's great to see that lmms works with it for 10 years now, but this is not sufficient to "just" put libwine on a public path (again). Instead we have to look into correct symbol handling (and I never did that before). The solution must be maintainable basically forever to keep it in the packages. Other team members have to be fine with it, too. I'd also check with upstream if they are fine with libwine... being on this path, but I guess they are. Greets jre
Bug#852494: wine: Add libwine.so and libwine.so.1 alternatives
El ds 19 de 05 de 2018 a les 23:39 +0200, Jens Reyer va escriure: > I definitely want the well-established system command > "update-alternatives" to be used. What are the requirements? "update-alternatives --config wine" must work if wine or wine- development are installed. Only this one? smime.p7s Description: S/MIME cryptographic signature
Bug#852494: wine: Add libwine.so and libwine.so.1 alternatives
Hi, sorry I thought I had answered to this. On 17.01.2018 17:56, Javier Serrano Polo wrote: > X-Debbugs-CC: k...@codeweavers.com > > El dc 17 de 01 de 2018 a les 15:48 +0100, Jens Reyer va escriure: >> 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"). > > You want to configure with "update-alternatives --config wine", but I am > asking to configure with "update-wine-alternatives --config" instead. > The update-wine-alternatives script does not exist yet. > [...]>> - Imo we should stay with pkg:wine(-development) providing the >> master /usr/bin/wine > > Jens, you should first understand what I am proposing. Is it fine to > configure with "update-wine-alternatives --config" and not have unneeded > wine packages installed? I definitely want the well-established system command "update-alternatives" to be used. Replacing this with a script "update-wine-alternatives" is not acceptable. If you can come up with a solution which works in your sense additionally to this, we can try it. Greets jre
Bug#852494: wine: Add libwine.so and libwine.so.1 alternatives
X-Debbugs-CC: k...@codeweavers.com El dc 17 de 01 de 2018 a les 15:48 +0100, Jens Reyer va escriure: > 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"). You want to configure with "update-alternatives --config wine", but I am asking to configure with "update-wine-alternatives --config" instead. The update-wine-alternatives script does not exist yet. > 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." When Ken made those statements, he obviously did not know about LMMS. libwine is a general-purpose library to run software that uses Windows API; this is the point of winegcc. libwine calls exit(), so what? Although libwine could call wine_exit_handler() instead of exit(). > To sum up, these are the issues: > - upstream considers libwine to not be a general-purpose library First, this is only a statement from Ken, not documentation. Second, he did not know about LMMS. Third, libwine is a Windows API provider. > - I'm not sure how stable its api is LMMS has been using Wine for more than ten years. API is stable enough. > - Imo we should stay with pkg:wine(-development) providing the > master /usr/bin/wine Jens, you should first understand what I am proposing. Is it fine to configure with "update-wine-alternatives --config" and not have unneeded wine packages installed? smime.p7s Description: S/MIME cryptographic signature
Bug#852494: wine: Add libwine.so and libwine.so.1 alternatives
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
Bug#852494: wine: Add libwine.so and libwine.so.1 alternatives
> There are no reverse dependencies of libwine, so it is not clear to me > how this would actually be helpful. Sorry, I missed your message. lmms-vst-server depends on wine, but I cannot help with lmms-related packaging right now. 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. smime.p7s Description: S/MIME cryptographic signature
Bug#852494: wine: Add libwine.so and libwine.so.1 alternatives
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
Bug#852494: [pkg-wine-party] Bug#852494: wine: Add libwine.so and libwine.so.1 alternatives
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? Best wishes, Mike
Bug#852494: wine: Add libwine.so and libwine.so.1 alternatives
Source: wine Version: 1.8.6-3 Severity: wishlist Please add a libwine.so.1 alternative to libwine packages, and libwine.so to libwine-dev ones. These alternatives should be placed under /usr/lib/MULTIARCH so that applications depending on libwine avoid the use of RUNPATH and the binary-or-shlib-defines-rpath lintian error. 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. smime.p7s Description: S/MIME cryptographic signature
