Hey!
Following up: I dove into the script to investigate further, and found out that the part where it was failing was when it attempts to run the original installer with some flags to extract the contents to some directory to manipulate further.
So I tried to run manually the installer, without the -y flag so that it would prompt me to confirm installation and allow me to abort it.
Doing that, I found out that the original installer complains about the following packages, which are not included on a fresh 22.04 LTS install (and probably were installed on 20.04 LTS, or were dependencies of something, and were being carried over through updates). Also, I am guessing previous versions of resolve didn't require them, because on those same fresh 22.04 installs, resolve 18.0 and previous ran without issue.
- Code: Select all
Error: Missing or outdated system packages detected.
Please install the following missing packages:
libxcb-composite0 libxcb-cursor0 libxcb-damage0
libxcb-xinerama0 libxcb-xinput0
So if I run:
- Code: Select all
sudo apt install -y libxcb-composite0 libxcb-cursor0 libxcb-damage0 libxcb-xinerama0 libxcb-xinput0
Then the script finishes normally, and outputs a .deb package that I can install, and resolve opens up and runs without problem. Also, if after that I attempt to install a package made on my other machines, it also installs.
So, if you are on 22.04 and are getting the "xbc" error, just install those packages and run again. The problem comes from missing dependencies for this version of resolve, not from an error on the functionality of the script itself.
As for the script, my only issue is that it didn't alert me of the names of the missing packages, as it normally would do. Because the message was more cryptic and didn't mention the names of specific packages (there are a lot of libxcb related ones), the problem seemed more serious. Also, from the error message, I am guessing that because of the -y flag the installer skipped the alert on the missing files and did try to run, which might be part of the problem as of why the script didn't catch that one.
Now, commenting on the post by Dwaine, I would like to shed some light into why makeresolvedeb is preferred instead of running the installer directly. The problem has never been that it won't install, but that it will do it in a non-standard way for a Debian based system, without full visibility for the package manager and putting some things in non-standard paths. Which would lead into eventual issues and headaches. So the makeresolvedeb script is more about cleaning house and reproducing a standard Debian installation.
Quoting Daniel from his site:
The native installer will install Resolve on your Debian based system but it will violate the Debian concept of fully tracked installations. The native installer forces software components into place and modifies parts of the OS in a way that is unbeknown to the Debian package manager. This practice will impede system reliability. MakeResolveDeb aims to solve that issue while including the Debian specific features required for a working Resolve system.
That means that with some tweaking to the installation script, Blackmagic could relatively easy make an official installer, because the program actually runs with full functionality and no alterations are needed to the code itself. The only issues that I am aware of from not running it on CentOS are that Fusion will not find Python where it expects it, so some symlinks are necessary to make Python 3 in particular visible to the program. Which wold be cool if it wasn't necessary, but it is livable.
Lastly, I would also love to point out to Bitwig Studio and how they are releasing their quite complex DAW as a flatpak app, with full funcionality and full access to any hardware that it needs. It would be very exciting and I believe way more practical, if Blackmagic decided to explore this distribution agnostic method.