[Ubuntu/debian] wine-tkg installs dependencies incorrectly, bricking my system

[Hexcede]

When compiling wine via wine-tkg, dependencies are automatically installed by the script.

The problem is that when wine-tkg's non-makepkg-build.sh script is ran on some systems, like my own, it incorrectly downgrades or reinstalls several critical system dependencies because they are both dependencies of the system, and of wine-tkg, and some kind of conflict about what has what dependencies arises from this.

The result is that the next time any apt command is ran, apt will prompt to auto remove hundreds of automatically installed packages, and there is no way to avoid this without passing an additional argument to apt when performing any action. Even with this obnoxious workaround, apt is left in a terrible state where many packages are marked as manually installed when they shouldn't be, and many automatically installed packages (critical to the system) want to be auto removed.

This bricks my system every time the wine-tkg script is ran, and it is indescribably infuriating to deal with, it requires that I fresh install my OS, which takes many hours, and is very stressful because I must manually back up all of my important files on a separate drive, go through the install process, and reconfigure all settings, applications, etc.

Please fix this ASAP, I have dealt with it more times than I can count.

[Tk-Glitch]

Finally someone who can understand how painful it is for me to do anything with apt distros.
Time to nuke support for apt I guess. I've dreamed of that for a while now tbh.

Joking aside, apt and distros using it have been the most infuriating stuff I've had to work with in the past decade, and at this point and following your report, what I think is the best thing to do is disabling the dependency installer outside of GitHub actions.
That way people who want to build wine on those distros will have to go through the dependency resolution themselves or use a container (which should absolutely be preferred on those distros). Between the broken packages they ship and the ever growing list of broken inter-dependencies with devel and i686 packages they simply don't want to fix, we shouldn't have tried to offer support for anything else than Debian unstable on the apt front, and even there we have to face broken packages for months or even years sometimes (sdl2-devel flashbacks) so all in all is it even worth it? I'm honestly not convinced.

[Hexcede]

I am glad that I'm not the only one who is frustrated with how apt works haha.

It sounds like removing automatic dependency installation is the way to go. I did come up with an alternative below though but it honestly just might not be worth the effort of implementing.

apt satisfy

After some Googling it looks like there's actually a feature which is meant for exactly this. When apt version is > 1.9.x (I don't know the exact version), the apt satisfy subcommand is available which would allow automatically installing dependencies from a dependency string (same as found in a .deb file)

It still has similar drawbacks to apt install but it doesn't mark packages, it won't re-install anything that is already met, and it better handles conflicts and allows you to specify your own. It essentially resolves dependencies as if installing a .deb with the given dependency string (which is basically what is desired). It would be possible to check if the subcommand is available by grepping the output of apt help for satisfy, or checking the output of running apt satisfy (sudo not required).

Note that a string like this might be passed to apt install: gcc>=4.5.0-2 fontforge
But for apt satisfy this string would instead need to be: gcc (>= 4.5.0-2), fontforge

Examples of the output

(I stole some package names from PKGBUILD for demonstration purposes)

• When there are conflicts:
  
• lib32-attr is not a package for my system (would be attr:i386)
  
• NOT successful result (pkgconf conflicts with my system's pkg-config, and accepting this prompt would be a death wish since many packages rely on pkg-config):
  
• Successful result (need to install some dependencies):
  
• Successful result (all dependencies already met):
  

[Tk-Glitch]

I remember toying with this before and I faced issues I can't remember. I'm not against trying it again though, as things might have improved since.

[Kerrung]

I'm glad my distro is Arch Linux and not an apt based one - that's happiness in my opinion.

[melroy89]

Aptitude at least gives you better insides in what is the ROOT cause... The debian solution is just remove all essential packages from your distro, that is not good.

But maybe this gives us better insides in what is really going wrong. See:

De volgende pakketten hebben niet-voldane vereisten:
 libx265-179:i386 : Vereisten: libnuma1:i386 (>= 2.0.11) maar het zal niet geïnstalleerd worden
 libgcrypt20-dev : Conflicteert met: libgcrypt20-dev:i386 maar 1.8.5-5ubuntu1.1 zal geïnstalleerd worden
 libgcrypt20-dev:i386 : Conflicteert met: libgcrypt20-dev maar 1.8.5-5ubuntu1.1 is geïnstalleerd
 libgphoto2-port12:i386 : Vereisten: libltdl7:i386 (>= 2.4.6) maar het zal niet geïnstalleerd worden
 libgphoto2-6:i386 : Vereisten: libgd3:i386 (>= 2.1.0~alpha~) maar het zal niet geïnstalleerd worden
                     Vereisten: libltdl7:i386 (>= 2.4.6) maar het zal niet geïnstalleerd worden
 libgpg-error-dev : Conflicteert met: libgpg-error-dev:i386 maar 1.37-1 zal geïnstalleerd worden
 libgpg-error-dev:i386 : Conflicteert met: libgpg-error-dev maar 1.37-1 is geïnstalleerd
 libswresample3:i386 : Vereisten: libsoxr0:i386 (>= 0.1.0) maar het zal niet geïnstalleerd worden
 python3-ldb : Conflicteert met: python3-ldb:i386 maar 2:2.2.3-0ubuntu0.20.04.2 zal geïnstalleerd worden
 python3-ldb:i386 : Conflicteert met: python3-ldb maar 2:2.2.3-0ubuntu0.20.04.2 is geïnstalleerd
 valgrind : Conflicteert met: valgrind:i386 maar 1:3.15.0-1ubuntu9.1 zal geïnstalleerd worden
 valgrind:i386 : Conflicteert met: valgrind maar 1:3.15.0-1ubuntu9.1 is geïnstalleerd
 python3.8 : Conflicteert met: python3.8:i386 maar 3.8.10-0ubuntu1~20.04.4 zal geïnstalleerd worden
 python3.8:i386 : Conflicteert met: python3.8 maar 3.8.10-0ubuntu1~20.04.4 is geïnstalleerd
 gdb : Conflicteert met: gdb:i386 maar 9.2-0ubuntu1~20.04.1 zal geïnstalleerd worden
       Conflicteert met: gdb:i386 maar 9.2-0ubuntu1~20.04.1 zal geïnstalleerd worden
 gdb:i386 : Conflicteert met: gdb maar 9.2-0ubuntu1~20.04.1 is geïnstalleerd
            Conflicteert met: gdb maar 9.2-0ubuntu1~20.04.1 is geïnstalleerd
 python3 : Conflicteert met: python3:i386 maar 3.8.2-0ubuntu2 zal geïnstalleerd worden
 python3:i386 : Conflicteert met: python3 maar 3.8.2-0ubuntu2 is geïnstalleerd
 libqt5quick5-gles : Conflicteert met: libqt5quick5 maar 5.12.8-0ubuntu1 is geïnstalleerd
 libllvm12 : Breekt: libllvm12:i386 (!= 1:12.0.1-1~oibaf~f) maar 1:12.0.0-3ubuntu1~20.04.5 zal geïnstalleerd worden
 libllvm12:i386 : Breekt: libllvm12 (!= 1:12.0.0-3ubuntu1~20.04.5) maar 1:12.0.1-1~oibaf~f is geïnstalleerd
 python3-minimal : Conflicteert met: python3-minimal:i386 maar 3.8.2-0ubuntu2 zal geïnstalleerd worden
 python3-minimal:i386 : Conflicteert met: python3-minimal maar 3.8.2-0ubuntu2 is geïnstalleerd
 libpulse0:i386 : Vereisten: libapparmor1:i386 (>= 2.7.0~beta1+bzr1772) maar het zal niet geïnstalleerd worden
                  Vereisten: libasyncns0:i386 (>= 0.3) maar het zal niet geïnstalleerd worden
                  Vereisten: libsndfile1:i386 (>= 1.0.20) maar het zal niet geïnstalleerd worden
 python3.8-minimal : Conflicteert met: python3.8-minimal:i386 maar 3.8.10-0ubuntu1~20.04.4 zal geïnstalleerd worden
 python3.8-minimal:i386 : Conflicteert met: python3.8-minimal maar 3.8.10-0ubuntu1~20.04.4 is geïnstalleerd
 libavutil56:i386 : Vereisten: libva-drm2:i386 (>= 1.3) maar het zal niet geïnstalleerd worden
                    Vereisten: libva-x11-2:i386 (>= 1.3) maar het zal niet geïnstalleerd worden
 libtheora0:i386 : Vereisten: libogg0:i386 (>= 1.1.0) maar het zal niet geïnstalleerd worden
 xserver-xorg-dev : Conflicteert met: xserver-xorg-dev:i386 maar 2:1.20.9-2ubuntu1.2~20.04.2 zal geïnstalleerd worden
 xserver-xorg-dev:i386 : Conflicteert met: xserver-xorg-dev maar 2:1.20.13-1ubuntu1~20.04.2 is geïnstalleerd
 libxfont-dev : Conflicteert met: libxfont-dev:i386 maar 1:2.0.3-1 zal geïnstalleerd worden
 libxfont-dev:i386 : Conflicteert met: libxfont-dev maar 1:2.0.3-1 is geïnstalleerd
 libqt5gui5-gles : Conflicteert met: libqt5gui5 maar 5.12.8+dfsg-0ubuntu2.1 is geïnstalleerd
 gdbserver : Conflicteert met: gdbserver:i386 maar 9.2-0ubuntu1~20.04.1 zal geïnstalleerd worden
 gdbserver:i386 : Conflicteert met: gdbserver maar 9.2-0ubuntu1~20.04.1 is geïnstalleerd
 libvorbis0a:i386 : Vereisten: libogg0:i386 (>= 1.1.0) maar het zal niet geïnstalleerd worden

[Tk-Glitch]

It's not really a fix as is, as different apt distros ship different packages. What works on Debian won't work on Ubuntu, and inversely. The worst example begin Pop!_OS which has the most broken package base of all apt distros (all distros?), that simply doesn't allow to build wine 32-bit at all.

@Hexcede We are clear that you have set _nomakepkg_dep_resolution_distro="debuntu"? I don't remember making an actual detection that enables automatic dependency installer for debuntu, but maybe I did and forgot? 🐸
I can't see it in the script though.

[melroy89]

I don't remember making an actual detection that enables automatic dependency installer for debuntu, but maybe I did and forgot? frog

You didn't FROGgot it. It's documented here: https://github.com/Tk-Glitch/PKGBUILDS/wiki/wine-tkg-git 🐸

[Hexcede]

It's not really a fix as is, as different apt distros ship different packages. What works on Debian won't work on Ubuntu, and inversely. The worst example begin Pop!_OS which has the most broken package base of all apt distros (all distros?), that simply doesn't allow to build wine 32-bit at all.

@Hexcede We are clear that you have set _nomakepkg_dep_resolution_distro="debuntu"? I don't remember making an actual detection that enables automatic dependency installer for debuntu, but maybe I did and forgot? frog I can't see it in the script though.

Yep, I have set it to debuntu in my configuration. At the moment I've been using an Ubuntu docker container to build inside of (can't build on anything but Ubuntu as far as I can tell, tried a few different debian-based containers without luck), and just sharing my wine-tkg folder. The docker container gets left in a broken state too, but it isn't my main system, and it has much less required to let it keep booting, so I don't have to worry. I can always just create another container, after all.

I can confirm that the breakage happens during building 32 bit wine. Particularly the worst effects from this come down to apt wanting to remove my graphics drivers, various packages related to my desktop environment, and a couple essential system packages as well.

I believe what happens is the 32 bit version of an existing system package is selected, which causes that package to be re-installed by apt (because as far as apt is concerned they're not two different packages, they're two different versions, and you're trying to downgrade/upgrade, because logically you'd totally want to downgrade to a bunch of 32 bit packages on a 64 bit OS, and there's totally not any usecase where you might need both at once). This causes all of the 64 bit versions of those packages to no longer be depended upon (and the 32 bit versions not to be installed), which causes apt to want to autoremove all of those packages, and all the things that they depend on, which are typically system packages, some of which aren't depended upon by anything else, making them "unused".

[melroy89]

Regarding Docker builds. I did that in the past as well (2 years ago). See: https://hub.docker.com/r/danger89/wine-pkgbuilds (using Arch). I'm not sure about the state of the current image.

[SveSop]

Building wine with the tkg-script is "at your own peril" i would say, but it is not overly horrible with Docker - especially since it wont break anything.

If i were to actually recommend building a .deb package (if that is what is wanted), i can highly recommend building it on OBS (The same build system that WineHQ uses to build their ubuntu/debian packages).

Easy for me, hard for others.. as much Linux stuff usually is.

Just building a standalone wine setup that you can use with eg. lutris or the likes, i would build with Docker. Debian/Ubuntu is notoriously horrendous when it comes to multilib support, and it will not change. Hopefully wine will be done with the 32-bit requirements eventually, so it will be a thing of the past.

[andrebadaia]

Hi, I could compile wine-tkg on Linux Mint Una (Ubuntu Focal). To avoid breaking system, do not install the packages gdb:i386 gdbserver:i386 libgcrypt20-dev:i386 libgpg-error-dev:i386 libxfont-dev:i386 samba-dev:i386 python3-minimal:i386 python3.8:i386 python3.8-minimal:i386 (the problematic packages). Do not set _nomakepkg_dep_resolution_distro="debuntu", but install packages related (go to script wine-tkg-git/wine-tkg-scripts/deps) to verify what 32-bits packages should be installed. If you need 32-bit samba and gcrypt, get the 32-bit packages from Ubuntu packages website, unpack them and copy the usr/lib/i386-linux-gnu folder to system /usr/lib/i386-linux-gnu folder. Works perfectly!

/opt/wine-tkg-git/bin/wine --version
wine-7.9-141-g99ce6e87a3b ( TkG Staging Esync Fsync )

[melroy89]

Wauw this is great news! Should we consider updating the wine-tkg script for Ubuntu? So those breaking packages are removed from the script. And give the user a warning about those remaining packages?

[melroy89]

Update: I also found this experiment where they managed to build wine statically. that would be interesting as well for wine-tkg. https://github.com/MIvanchev/static-wine32

[Inve1951]

this really needs a giant warning in the readme ⚠️ ⚠️ ⚠️ ⚠️ ⚠️
i also just fell victim to this
was able to get the removed packages back by installing them again (see /var/log/apt/history.log) but now dependencies are no longer flagged as such but as explicit installations which surely will lead to headaches when upgrading stuff in the future
some configurations also got destroyed and i can't even tell the extent of it

and to top it off, despite the build script reporting success, the packaged build is nowhere to be found.

[ryleu]

A Nix flake for building would be a great solution for this problem. It would let apt people easily build without having to worry about a bricked system.

[Kid0h]

I did not get any of my packages removed..

this really needs a giant warning in the readme warning warning warning warning warning i also just fell victim to this was able to get the removed packages back by installing them again (see /var/log/apt/history.log) but now dependencies are no longer flagged as such but as explicit installations which surely will lead to headaches when upgrading stuff in the future some configurations also got destroyed and i can't even tell the extent of it

But this is very much the case.

and to top it off, despite the build script reporting success, the packaged build is nowhere to be found.

[sylv256]

this is a very serious issue
i just want to play roblox pleas

[Tk-Glitch]

Ubuntu can't build wine cleanly in its own env because of broken packages. Nothing to do here except for canonical to fix their mess - which is unlikely to happen - or to wait for 32on64 to be ready on the wine side to disable using 32-bit libs altogether. In the meantime just don't set any distro in your .cfg and no package will be installed/removed.

[sylv256]

is there a way to undo the command after it's run? I didn't know I didn't need the distro.
Specificially, I ran ./non-makepkg-build.sh
I'm not sure if I just fucked up my package manager permanently or what.
Update: there's nothing in autoremove, so am I fine?
Update 2: it appears it didn't finish anyways. I removed debuntu so now it's at default. (sorry for spam)

[melroy89]

Hi, I could compile wine-tkg on Linux Mint Una (Ubuntu Focal). To avoid breaking system, do not install the packages gdb:i386 gdbserver:i386 libgcrypt20-dev:i386 libgpg-error-dev:i386 libxfont-dev:i386 samba-dev:i386 python3-minimal:i386 python3.8:i386 python3.8-minimal:i386 (the problematic packages). Do not set _nomakepkg_dep_resolution_distro="debuntu", but install packages related (go to script wine-tkg-git/wine-tkg-scripts/deps) to verify what 32-bits packages should be installed. If you need 32-bit samba and gcrypt, get the 32-bit packages from Ubuntu packages website, unpack them and copy the usr/lib/i386-linux-gnu folder to system /usr/lib/i386-linux-gnu folder. Works perfectly!

/opt/wine-tkg-git/bin/wine --version wine-7.9-141-g99ce6e87a3b ( TkG Staging Esync Fsync )

Here is a solution. And wine tkg could actually do something. Changing the script for Ubuntu distro.

[Tk-Glitch]

Sadly it's more of a workaround. There are also special quirks that apply to mint that wouldn't apply to buntu, or debian.. All debian/buntu distros aren't equal on the package quality/freshness and it's so brittle it breaks every few updates. The CI allows us to target buntu 20.04 which is an acceptable middle ground (I couldn't reproduce a system-wide breakage on 20.04 testing VMs with our current dependency list), but clearly Fedora and Arch based distros are in a much better shape for the job.
I am working on a few hacks to help the situation for proton building on debuntu but it's a headache. The aging toolset of Ubuntu collides with our bleeding edge needs in very annoying ways.
The initial desire of disabling the debuntu dep resolver altogether out of the CI actually annoys more people than I thought so it became undesirable. Adding fat warnings doesn't stop anyone so we need to find an alternative. Offering a container based building env might be a temporary "solution", but again that's a large amount of work for something that should become a non-issue in the near future with 32on64.
I'm open to more ideas as to the best way to please everyone as I may not have thought about all the possible solutions.

[Inve1951]

The typical build it on your system experience is that the user is provided a list of necessary packages/libraries in the readme/wiki and installs those however they see fit.
Automatically doing this for the user is nice to have but by no means necessary; and undesired if there's risk of damage.
I haven't looked into how the installing of packages is currently done, but it must be using some dangerous flag cause when installing stuff on the command line i've always at least gotten warnings about conflicts and never had apt just mow down what's there by itself. You'd have to force it to do so.

[Fox2Code]

Ubuntu/debian apt break itself so much it's better to use ArchLinux.

I had a more stable experience with ArchLinux than with Ubuntu or Debian.

This is the reason why I hate apt based (Ubuntu/Debian) distros so much.

[Sukid]

Just ran it on my popOS 22.04 system and everything seems to be fine. Big improvement since the last time I attempted this on popOS a year ago! So at the very least, that distro seems to be safe.

[sylv256]

Ubuntu/debian apt break itself so much it's better to use ArchLinux.

I had a more stable experience with ArchLinux than with Ubuntu or Debian.

This is the reason why I hate apt based (Ubuntu/Debian) distros so much.

Seconded. Arch has given a far more stable experience for us*.

[suamor]

Remarks regarding 22.04: 64bit-dependencies work still fine

I have tried to install 32bit-dependencies and found that installing samba-libs:i386 as well as python:i386 dependencies can't be installed currently on Ubuntu without removing large parts of gnome and more.

xserver-xorg-dev:i386 and libgcrypt20-dev:i386 and valgrind:i386 and rustc:i386 directly conflicts with it's 64bit variant.

I needed to switch update-alternatives for gcc and g++ (i.e. first g++, then gcc) to make them work.

In my build test I removed these packages from the "deps" file (see renamed attachment due to github limitations
deps.txt
).

I needed to change the "own" patch since loader.c has additionally code (attached renamed patch due to github limitations).
de-steamify-80-exp.txt

This was reported in 2022 and no point on the discussion of the issues was reached so far:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1993081

My recommendation is to leave out those dependencies completely for (at least) Ubuntu systems.
Since in a few months the next LTS is released and 2020 nearing it's end, do not recommend such an old Ubuntu for building. Latest in april 2022 should be in a buildable state.

I hope that 32bit changes in wine 9.0 will make it easier to handle the 32bit build topic in the future.

Back to the build: non-makepg-build seems to work. The proton skript which i run afterwards exit with
:
/usr/lib/git-core/git-remote-https: symbol lookup error: /usr/lib/git-core/git-remote-https: undefined symbol: curl_global_sslset, version CURL_GNUTLS_3

Analysis.
(comes from non-makepkg-build.sh, could be part of git, but it's not a regular system package).
Strange enough same script as before, but issue only appears with proton generation.
I have temporarily fixed this by building a backport of latest git 2.43 myself (from 24.04 repository).

As written before, both 64bit and 32bit rust can't be installed in parallel on Ubuntu (at least I have found no way). This is strange, since there is proton available for Ubuntu. How is this achieved?
I decided to install the same rustc for both environments with rustup but use the version from Ubuntu to avoid issues.

mingw Version of 22.04 is broken. You need either 22.10 (obsolete), 23.04 (obsolete in 2 weeks) or 23.10. I still found 22.10 and currently use this. a backport from 23.10 could be needed if some dependencies are not met.

Configuration, part 2: TKG proton / wine has options allowing to switch to stable or staging 9.0. Also when building proton tkg there are not only three, but 4 options to choose from (experimental / proton). I choose the most current one as that most likely works best with current wine.

Tests: I tested with the linux install script for MO2. From there I switched to my own build version 9.0/proton. I have manually exchanged MO2 (2.5.1rc) and could launch this as well as the latest LOOT. For the game to work you need to start with proton if you use command line.

[roguehub]

will it work if i build it on Arch then copy it to Debian?

[melroy89]

will it work if i build it on Arch then copy it to Debian?

Most likely yes, assuming it's the same platform (eg. amd64). Maybe it could cause issues with libc or other runtime problems.