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
