Wine installer broken in non ahs version (Solved) [Solved]

[tony37]

So it must have been because you installed minitube from the test repo (version 3.6.5-0.1~mx19+1). That pulled in libavdevice58, so other ffmpeg packages got upgraded as well (and because of that, also the libva packages)

[JayM]

I don't remember if it was from the test repo or not, but if you're wondering why I installed it in a VM, this is why. I use the VM to test, check and try things without risking messing up the host system. That's why I said it's probably high time I reinstalled: there's a high level of cruft on it.

[tony37]

The main problem is just that once the ffmpeg packages come from test, then the 32-bit versions (needed for wine) need to come from there as well. So how to solve this? Maybe doing a preinstall check which version is installed, and installing some packages from the test repo if needed? Could become complicated

I couldn't help myself and tried to write a script for this. It may still be a bit amateurish, but it worked when I tested it. (update: I improved a few things and think it should be fine)
So I wrote a file called /usr/share/mx-packageinstaller-pkglist/wine_script.sh with following content:

Code: Select all

#!/bin/bash

# this list can be generated with: echo $(aptitude search '?source-package(^ffmpeg$)' -F %p)
ffmpeg_list="ffmpeg ffmpeg:i386 ffmpeg-doc libavcodec-dev libavcodec-dev:i386 libavcodec-extra libavcodec-extra:i386 libavcodec-extra58 libavcodec-extra58:i386 libavcodec58 libavcodec58:i386 libavdevice-dev libavdevice-dev:i386 libavdevice58 libavdevice58:i386 libavfilter-dev libavfilter-dev:i386 libavfilter-extra libavfilter-extra:i386 libavfilter-extra7 libavfilter-extra7:i386 libavfilter7 libavfilter7:i386 libavformat-dev libavformat-dev:i386 libavformat58 libavformat58:i386 libavresample-dev libavresample-dev:i386 libavresample4 libavresample4:i386 libavutil-dev libavutil-dev:i386 libavutil56 libavutil56:i386 libpostproc-dev libpostproc-dev:i386 libpostproc55 libpostproc55:i386 libswresample-dev libswresample-dev:i386 libswresample3 libswresample3:i386 libswscale-dev libswscale-dev:i386 libswscale5 libswscale5:i386"
# this list can be generated with: echo $(aptitude search '?source-package(^libva$)' -F %p)
libva_list="libva-dev libva-dev:i386 libva-drm2 libva-drm2:i386 libva-glx2 libva-glx2:i386 libva-wayland2 libva-wayland2:i386 libva-x11-2 libva-x11-2:i386 libva2 libva2:i386 va-driver-all va-driver-all:i386"

if [[ -n $(grep 'Package: libavutil56' /var/lib/dpkg/status) ]]; then
    if [[ -n $(apt-cache policy libavutil56 | grep -m1 '/var/lib/dpkg/status\| 500 ' | grep status) ]]; then
        echo -e "Package: $ffmpeg_list\nPin: release a=mx,c=test\nPin-Priority:500\n" >> /etc/apt/preferences.d/tmp_wine_preferences
    fi
fi

if [[ -n $(grep 'Package: libva2' /var/lib/dpkg/status) ]]; then
    if [[ -n $(apt-cache policy libva2 | grep -m1 '/var/lib/dpkg/status\| 500 ' | grep status) ]]; then
        echo -e "Package: $libva_list\nPin: release a=mx,c=test\nPin-Priority:500\n" >> /etc/apt/preferences.d/tmp_wine_preferences
    fi
fi

if [ -e /etc/apt/preferences.d/tmp_wine_preferences ]
    then echo "deb http://mxrepo.com/mx/testrepo/ buster test">/etc/apt/sources.list.d/mxpitemp.list && apt-get update
fi

and then I put '/usr/share/mx-packageinstaller-pkglist/wine_script.sh' in the preinstall instructions of Wine.pm, and added

Code: Select all

rm -f /etc/apt/sources.list.d/mxpitemp.list /etc/apt/preferences.d/tmp_wine_preferences

to the postinstall instructions.

edit: I decided it was better to have all packages from the ffmpeg/libva source package in the preferences list, because some could be in need of an update if the current test version is more recent than the originally installed test version.

[SwampRabbit]

I think the easier long term solution would be for the i386 packages to be installed with the amd64 packages when installing from the MX Test Repo.

Maybe I’m wrong, but any other option coming to mind means maintaining/updating other work arounds like your script.

[tony37]

One problem with installing the 32-bit packages automatically is that they pull in a lot of stuff: libavcodec58:i386 pulls in 77 other packages for me.
What you would have to maintain using my script would be: checking if more packages are needed when a newer Wine version comes out. But I did a check with the current 6.4 version in the test repo and I see no extra dependencies. (edit: although the way I have the script now, I think you wouldn't even need to check this, just every major release you'd have to check if 'buster' needs to be 'bullseye', or if some packages have changed names)
It's true that this would only solve the problem for Wine, not potential other conflicts. But then you'd need to have a general preferences file with all ffmpeg + libva packages from mx test pinned to 500, and the test repo would have to stay enabled then.
I think most non-Wine problems can be fairly easily solved, like "install ffmpeg from the test repo tab in MXPI" or "install this/that dev package from the test repo". But when someone doesn't want the test version of Wine, then it gets complicated.

[SwampRabbit]

I’d have to look later, but if those i386 packages are going to get pulled in anyway sooner or later, than I don’t see an issue with it unless we are talking a ton of extra space being wasted. They may get used/be needed later anyway.

If someone is using the MX Test Repo to install anything, they should be expecting to deal with any consequences anyway. And they are probably going to pull in a done of different random amd64 and i386 packages either way.

We created this problem because we provide a tons of options for newer software for users, for sure don’t want to take that away, but I also don’t want to (or anyone else to have to) update a script of do extra work because we update something.

Mike does enough just packaging WINE and putting it through it’s paces before users get it. Stevo and I do enough with libva and ffmpeg every so often.

If anything I’d like to make things easier and faster for everyone, including users. The solution should be smarter, not harder. And by harder I mean no extra work or hassle for anyone.

This issue we have right now tells me we either need to slow down, test things more before putting them in the MX Test Repo, and probably pay attention to some details better.

We pride ourselves in the fact that the MX Test Repo is pretty much 99.99% stable and issue free. We try really hard to keep it that way, so when things like this pop up it’s depressing (to me at least) lol.

I’m going to defer to @Stevo, I’m game for whatever he decides.

[tony37]

What would be wonderful of course is if you could simply eliminate these libraries from the test repo. And say to people: if you want newer ffmpeg packages, use ahs.
But I think Kodi 19 really needs the newer versions, haven't found other packages though.

[SwampRabbit]

There are other packages, I found that out while testing the pre-release AHS stuff cause like I said it’s version is lower as well.

I think there is enough applications in the MX Test Repo that need the newer versions that moving it all into AHS only would negate what AHS is really just supposed to be for... newer hardware.

AHS isn’t meant to be a rolling version of MX, it’s not the goal, and we decided a long time ago to not make it that.

[tony37]

just a last thought: If you would automatically install some extra packages if ffmpeg packages get installed from the test repo, then I'd propose to install just 'ffmpeg' and 'libavdevice58' (both 64-bit). That would already solve a lot of possible problems, with just two packages. Because from what I can see, the only use case for those 32-bit packages (libavcodec58:i386 etc.) is Wine, even Steam doesn't need them. So doing something Wine-specific makes sense to me. Only problem that would remain is dev packages, but starting to install those for everyone feels like a no-go zone.