[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#932201: wine64 should also look for /usr/lib/wine/wineserver64 if WINESERVER is not set



Hi dkg and wine-team,

On 16.07.19 16:48, Daniel Kahn Gillmor wrote:
> wine64(1) says:
> 
>     WINESERVER
>               Specifies  the  path  and  name of the wineserver binary. If not
>               set, Wine will try to load /usr/lib/wine/wineserver, and if this
>               doesn't exist it will then look for a file named "wineserver" in
>               the path and in a few other likely locations.
> 
> But wine64 only ships with /usr/lib/wine/wineserver64.

Yes.

I'm working on a solution.  Feel free to stop reading here, following
are my thoughts on how to best solve this.


In Debian we rename the wineserver binary to wineserver32 and
wineserver64 to get the multiarch working. You only need one wineserver.
For multiarch Wine wineserver64 is used for all Wine prefixes (32-bit
and 64-bit). /usr/lib/wine/wineserver is our script to get this working.

I'm now trying to move this script to wine32 and wine64, so that these
two packages "share" this script.  I got an installable version just
now, but that has issues at least on uninstalling...

Maybe I also find a way to merge pkg:wine32 and pkg:wine64 in pkg:wine
(making the latter arch specific instead of arch:all).  But that would
be a major change in our packaging.  While I don't like a major change
here, I see a potential for a slight improvement of our packaging beyond
your report (if it is possible, the current status is really good).


> I'm finding that i need to set WINESERVER=/usr/lib/wine/wineserver64
> in libgpg-error's debian/tests/windows (an autopkgtest where we ensure
> that we can build a static windows executable against libgpg-error on
> debian), otherwise i get "could not exec wineserver".

Correct solution for now.


> It seems like wine64 should be smart enough to try
> /usr/lib/wine/wineserver64.
>
>  (aside about the overall problem space of using wine in autopkgtest:
>   i think if i installed the "wine" package, and then just invoked
>   /usr/bin/wine directly, instead of wine64, it would work correctly
>   for me,

Indeed, usually that would be the correct solution.  That's why I
(usually) tell people to just "apt install wine", which pulls in wine64.


>   but the problem with that is that "wine" sends a warning to
>   stderr about wanting wine32 installed upon every invocation, which
>   isn't possible on a non-multiarch system (and all the continuous
>   integration systems i've used thus far are non-multiarch).  And
>   messages to stderr are indicators to autopkgtest that the test is a
>   failure.  I could suppress the warning by setting WINEDEBUG=-all,
>   but i *don't* want to suppress any other warnings that wine might
>   produce.

This warning is from a Debian script, so you can't suppress it by
WINEDEBUG=-all.  We could invent our own variable to silence
/usr/bin/wine here.  But if you have to set a variable anyway, you can
just set WINESERVER as described above.  So not much to be gained this way.


>  So if you see a better way around this, so that i can use
>   wine in autopkgtest more easily, please don't hesitate to suggest
>   it)

My least favorite solution would be to patch the upstream source.

Greets!
jre


Reply to: