On Sun, Sep 14, 2014 at 3:49 PM, Tomas Janousek <t...@nomi.cz> wrote:
> On Sun, Sep 14, 2014 at 02:43:00PM -0400, Joseph Bisch wrote:
>> I think the problem is bigger than it initially appears. The patch
>> Andrey provides seems to only work for i386, not amd64. The
>> wine-development package only provides wine-development[0], whereas
>> wine provides wine[1]. Winetricks searches for a wine executable, not
>> the wine-development executable. The wine32-development package
>> provides a wine executable, which isn't provided by
>> wine64-development, which is why this only affects amd64, not i386. I
>> have attached a patch that appears to fix the wine-development issue
>> by searching for wine-development if wine can't be found.
>
> Well, wine32-development does provide a wine executable, but not in $PATH, so
> I don't think it matters and it should work equally well (or not well at all)
> on both architectures. I happen to have a i386 system and a "wine" in $PATH
> that execs wine-development, and when I remove it, winetricks complains that
>
> ------------------------------------------------------
> WINE is wine, which is neither on the path nor an executable file
> ------------------------------------------------------
>
> So I think that there's no amd64-specific problem and your patch isn't needed.
Line 3762[0] executes "which wine", which works with
wine32-development, because it provides a wine executable, but not
wine64-development, because that provides a wine64 executable. So on
amd64 I get the "WINE is wine, which is neither on the path nor an
executable file" without my patch. I guess this should be a separate
bug report. And the patch probably should be sent upstream.
> That being said, the logic in winetricks_init is likely wrong, as it tries
> "wine" first, but wineserver is searched in wine-{development,unstable} path
> first. That might go horribly wrong if both wine and wine-development is
> installed (which it isn't on this box). :-(
>
> I am not sure what the correct solution is. I'm starting to think that
> extending both of those error messages to tell the user to correctly set
> _both_ WINE and WINESERVER environment variables might be the only safe
> option (I'd even go as far as to never look for wine-{development,unstable}
> wineserver). And, as the comment suggests, persuade Debian wine maintainers
> to put wineserver back in path, ideally using alternatives so that it's easy
> to switch between wine and wine-development.
I agree that telling the user to set WINE and WINESERVER environment
variables sounds like a good option. And at the same time persuading
Debian wine maintainers to put wineserver in path.
[0] -
https://code.google.com/p/winetricks/source/browse/trunk/src/winetricks#3762
Cheers,
Joseph
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
