Page MenuHomeSolus

Wine not found
Closed, ResolvedPublic


Wine fails to be added to the PATH, I believe. PlayOnLinux and Q4Wine both fail to be find the wine binary as seen below, and bash doesn't find it, either. I checked that I have the package 'wine' installed, as well as /usr/bin/ for the physical binaries, and they're all there and can be executed regularly. I've uninstalled and reinstalled Wine to make sure it wasn't an error on my end. Probably just an issue with the install script?

On stable, Solus 1.2.1 and completely up to date.

Event Timeline

drakovyrn updated the task description. (Show Details)

I am also experiencing this problem. Also tried "wine program.exe", same problem.

Install wine-32bit, the main executable is part of it

JoshStrobl closed this task as Resolved.Oct 28 2016, 9:20 PM
JoshStrobl claimed this task.
JoshStrobl removed JoshStrobl as the assignee of this task.
JoshStrobl added a subscriber: JoshStrobl.

then why not make wine-32bit a dependency of wine?
ran into the same issue in 2018 :-(

Because not everyone needs to run 32-bit Windows applications.

true. but does not everyone expect wine in the path / menu after installing it?

I agree that 32-bit doesn't have to be installed for evrey user but there is no message informing the user why the installation failed after installing Wine. Wine should either install Wine32 as a dependancy (after all, playonlinux does) or the user should be informed when they try to install a 32-bit program that they need something more.

I would think there are more use cases for 32-bit wine than 64 anyway.

I certainly expect it to be in the menu / actually be able to run a Windows program after installing what's "supposed" to be WINE.

Honestly, the only reason I didn't make a fuss of it before was because I ended up not needing WINE, anyway.

I'd also be willing to bet that it would affect more people if 'wine-32bit' is not automatically installed with 'wine', than 'wine-32bit' being installed even if they don't necessarily need it.

It also goes against the philosophy of "Sane Defaults", where the user should be able to just install something and have it work. I know it probably makes sense to a developer to have them segregated, but a user will only get confused and then be forced to search help forums for what should otherwise be a straightforward procedure.

Not to mention, every other distro automatically installs WINE in this fashion. The reason I was originally confused by this in first place, was because Solus just happened to be the odd man out in this instance.

And of course, I'm all for the improvements that Ikey & Company™ come up with to improve the Linux ecosystem as a whole in Solus, but I fail to see where this plays into this bigger picture of "improvement".

So just to clarify, I think it would be in Solus' best interest to add 'wine-32bit' as a dependency of 'wine', to improve upon user experience, as well as further embrace the concept of Sane Defaults. And as you can see, others here would agree.

Solus is not other distro and polluting a 64-bit system with lot of extra 32-bit libraries for someone who don't need them is not exactly what I call "Sane Defaults", and I don't even mention to disk space wasted.
This has nothing to do with developer vs. end user but it's all about the applications that have to be installed on the system.

This is just my personal opinion, of course.

If we rundep wine-32bit onto wine we then end up with a circular dependency as wine-32bit already depends on wine. Not to mention the split with the devels..

robgriff444 added a comment.EditedFeb 24 2018, 1:21 PM

In my case, I wanted to install Oblivion so I installed WINE but Oblivion didn't install.

I worked out by looking at Playonlinux dependencies that I didn't have WINE-32 so I installed it and O installed fine.

A user today has a similar problem on the forum, there should be some form of a solution that prevents this from happening. A message in the SC next to WINE is probably enough.

Or rename wine to wine-64 and list it after wine-32 in SC ? It just needs to be clear, not automatically installed.

Not renaming it to include "64", we have automatic, well defined package naming policies. We're a 64-bit distro so nobody should assume the primary package is 32-bit.

Ok, but I saw wine and i installed wine and wine didn't work and wine didn't tell me why :-P

Surely, something should inform the user so they don't have to forum search?

I understand the sentiment, but it still doesn't help that installing 'wine' doesn't actually install 'wine'... if you understand what I mean.

A user won't care that there's a difference between 64-bit and 32-bit packages for compatibility with certain Windows applications, they just want to install the 'wine' package and run whatever program they have (regardless of whether that program is 64-bit or 32-bit).

The simple truth of the matter is, every other popular "desktop-user-oriented" distro lets you install some package 'wine' and then runs whatever program you need, 64-bit or not. Solus is the odd man out, here. Something isn't "right", from the viewpoint of a user.

I understand the burden that things like this can create for a dev, but if every other pop distro can do it, there _has_ to be some form of a solution (or even a compromise) that Solus can use. Otherwise, it just makes Solus look broken by default.

The only alternative then is we deprecate -32bit and -32bit-devel and merge the final packages, so that its a 32-bit + 64-bit package in one.

At this point I still argue that you're using assumptions based on other distros and applying their packaging polices to Solus and using it as justification for sane defaults, which I'm sorry to say is invalid.
However this conversation has gone on so freakin long now that I just want to make it stop. So we'll merge them.

(i.e. if this suits everyone, please say so, unless there is some alternative scheme? Otherwise i'll implement this tomorrow and we can all go back to being happy and less confused :))

Ikey, you're such a good man, thank-you for listening and I say yes go ahead with what you said UNLESS you can simply add a notice if a user installs wine and then tries to install a 32-bit program that says 'you need wine-32, go to SC' :-)

Nah I think the notice thing would then definitely put the ball in the court of "sane defaults", or lack thereof. You guys use wine, not myself, so my assumptions on its behaviour don't necessarily map correctly.
If its less fart-arsing around to do it this way then we do it

I'm not under the impression that anything any other distro does is sane (trust me, I didn't come to Solus because the others were too logical), I'm just saying that the norm of other distros has put Solus in a bad position, and it won't be as simple as ignoring the problem.

Personally, I think merging the packages is a suitable solution, as that's how I imagined it should be, but I think a message saying that 'wine-32bit' needs to be installed when 'wine' is installed should suffice. I don't know what use case someone would have to use only -32bit-devel, but I'd rather not exclude users to make it easier for others, if the Solus way would be better.

But if there would be little to no impact on users, and create less confusion, then I support that decision.

And thanks to Ikey and Team for hearing us out on this issue. We all just want Solus to be the best that it can be for users (and everyone else) without having to compromise an otherwise solid system. :)

julius16 added a comment.EditedFeb 25 2018, 6:50 AM

"The only alternative then is we deprecate -32bit and -32bit-devel and merge the final packages, so that its a 32-bit + 64-bit package in one."

I went through

  1. Install wine: wine not found
  2. install wine-32bit: app installs, but crashes instantly on run
  3. install mono and gecko: app crashes instantly
  4. install PlayOnLinux: app crashes instantly
  5. install PoL wine 3.2 (+mono + gecko): app crashes instantly
  6. run app from wine start menu entry: it works

I am feeling like a noob anyway because I do not know why my windows application is running.
I am unsure whether I have 2 binaries on my system or one (only the "wine" command is recognised in the terminal).
I just expect the normal wine package to install like any package, i.e. after installation the terminal and the start menu know the "wine" command (step 1 above).
But as I said, I do not fully understand my situation :-)