Sveinar
On 10.09.2021 18:10, Esme Povirk (she/they) wrote:
On Fri, Sep 10, 2021 at 3:49 AM Alexandre Julliard julliard@winehq.org wrote:
That would assume that all libraries find all their data based solely on the library path. That seems optimistic...
Note that the issue is not only with imported libraries, it could be using external config files or registry keys, all of these would have to be renamed as well.
I think this is usually the case based on the work I've done packaging open-source (primarily unix) libraries for Windows.
I also think that it should be the goal of upstream libraries or at least distributions to provide versions that are useful for targeting Windows, and an important part of that is being able to function in an application that doesn't know what directory it'll be installed to, and may not have an install process at all. Especially if distributions actively want us to use their packages, they should be willing to accept patches for that. It does of course leave us dependent on distributions instead of letting us take matters into our own hands, but that would be a problem anyway.
What about those "release distros" everyone love to hate? (Like Debian & family). Doing active development on said libraries when some distros have a 1+ year release policy - and rarely backport unless there is severe bugs. "Not our (WineHQ's) problem"? I mean, Debian testing (Bookworm) is still at wine-5.0.3. Bullseye that just got released is also at wine-5.0.3.... and in 3 months or so, i guess WineHQ is up to wine-stable-7.0.
I am not saying this won't change with some goodwill, but i do not hold high hopes for some of the slower release based distro's in that regard, especially if the list of "needed libs" grows exponentially fast :)