Using Debian 11 (Bullseye), there’s instructions to install from apt with the following sources.list:
deb http://download.opensuse.org/repositories/home:/strycore/Debian_11/ ./
But when that tries to upgrade from 0.5.11 to 0.5.12 it needs the package
gir1.2-webkit2-4.1 , which isn’t available in Debian 11 (Bullseye).
The 0.5.11 worked just fine, but I cannot upgrade to 0.5.12 because of what I describe above.
Apt output:
gusnan@debian-i7:~> LC_ALL=C sudo apt upgrade lutris
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
lutris : Depends: gir1.2-webkit2-4.1 but it is not installable
E: Broken packages
Yeah, you’re not the only one with that gir-webkit2 (gobject-introspection) dependency conundrum on .deb distros. Package version specific dependencies like that are utterly ridiculous and most of the time, unnecessary.
Just go download the latest Lutris deb for Debian 11 and install it with dpkg and force it. If you have the dependencies for 0.5.11 you have the dependencies for 0.5.12
I know this is safe IN THIS PARTICULAR SITUATION, but this is not something you should be in the habit of doing (forcing dependencies or conflicts when installing packages)
dpkg doesn’t have a separate “upgrade” command, -i (install) will upgrade if a package is already installed.
P.S. If you’d prefer to use a minimal amount of sledgehammering in the command, dpkg has a specific force switch for dependency VERSIONS, --force-depends-version that should be all you need for this (but the above will certainly work)
Ah, thanks - That indeed works. But that gives me even more complaints from apt on later upgrades, so I think I will stay at 0.5.11 and only need to apt-mark hold that version. (I think I can manage until Debian Bookworm is released).
But I would love to see the Lutris team provide a package of 0.5.12 properly built for Debian 11…
I ended up building the package from source, removing the faulty dependency for Bullseye, and use that in my personal apt archive. That works for me, but it would be great to not to have to do it. (And I can understand that Debian bullseye isn’t on the top of priorities, since there’s “soon” a new Debian release replacing it).
None of the objects actually compile, it’s just straight interpreted python (with bindings and libraries on the system etc.) being packaged up.
That’s how I would have solved it too, but part of the reason I don’t like those distros is because they make doing things like compiling packages unnecessarily difficult (i.e. I’d not tell someone in a forum “oh, just go rebuild the .deb” as they’d need everything-devel and have to figure out ridiculous syntax and variables in the controls)
I’m actually not so sympathetic to this… that’s BULLSHIT to not fix that package. It would take like a minute to edit the control file and repackage.
Most people (including yourself, evidently) would not like having to ignore apt’s complaints on every transaction.
Exactly - I can repackage for myself, but of course I fully understand that it isn’t a solution for everybody. - And it also has the drawback that I need to do it again on every next release.
Also, there isn’t any flatpak / snap solution or something like that that the developers keep updated?
I use (a heavily customized, gutted) Manjaro for my gaming system and I just maintain my PKGBUILD to roll up lutris-git when I see commits I want.
Lutris 0.5.13 beta1 (current lutris git) has some nice new features, not the least of which is the ability to use Proton builds from Steam again. (It finds your Steam runtime now)
