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
