Linux support/portability

Ideas & suggestions
1

This is a pretty technical/philosophical and hairy topic, so bear with me please.

I’ll try to be clear and concise. Scroll to the bottom for the gist of the post.

For simplicity, Renoise claims it “runs on Windows, Mac OS X and Linux”.

Now, Linux, depending on who you ask, is defined as either of three things:

Only the first two definitions are properly specified. The third, while simpler, is absolutely incorrect. An operating system is comprised of not only a Kernel, but of several other components, such as a standard library (specifically a C standard library, such as the glibc, or musl libc, or diet libc, etc.), a collection of various libraries, a shell, and various other programs (editors, compilers, etc.) that comprise the “user space” (AKA “userland”).

The TL;DR is: “Linux” in itself is just a very low-level component of an Operating System, and while it is possible to make up a family of all OS using Linux (the so called “Linux distributions”), no single OS can be called “Linux” on its own.

As a result, “supporing Linux” is a very imprecise goal, and if one really wants to achieve it, they would have to ship an entire “Linux distribution” as a product. That is not ideal.

You might wonder why I’m talking about all this…

The reason is that the “Linux” release of Renoise is lacking.

Here are the main problems I have identified:

  1. The scripts needlessly depend on bash, which may or may not be present on a given distribution. But the POSIX shell, virtually identical for the purposes of the Renoise scripts, is, by specification, always present.
  2. The renoise binary depends on (links to) various system libraries, which, on my devuan system, require the following packages: libasound2t64, libc6, libc6-amd64-cross, libc6-amd64-i386-cross, libc6-amd64-x32-cross, libc6-dev, libgcc-s1, libstdc++6, libx11-6, libxau6, libxcb1, libxdmcp6, libxext6.
  3. Several other binaries are present and dynamically linked, thus depending on specific libraries being present on the system.
  4. The install script exits with 1 upon success.
  5. The install script does not trap.
  6. The install script executes the (empty) output of some commands that are only supposed to validate the content of files (grep, etc).
  7. The install script has flawed logic (wrt checking the CPU governor and in a few other points).
  8. The install script assumes the presence of expected binaries, without checking.
  9. The install script does not seem to check the presence of the required dependencies (libraries).
  10. Your binary seems to depend on X11 (no wayland compatibility).

For fixing points 1, 4, 5, 6, 7, 8 and 9, a rewrite of the scripts is required.

For fixing points 2 and 3, static linking of your binaries is required. I don’t know how your code looks, or how your build system is, and this might be a herculean task. At the very least, the installation script should take care of ensuring the presence of the dependencies.

For fixing point 11, a specific development effort is required, which I wouldn’t be sure is worth doing at the moment.

Conclusion: as it stands, Renoise might very well work on a majority of Linux distributions (by user share), because of the utter lack of diversity in Linux distributions (they almost all use the glibc, systemd and GNU Bash). There are several possible improvements to mitigate this situation, with varying degrees of difficulty.

As a side note, I would be willing to provide you with a reworked version of the install script. Contact me via a direct message if you are interested.

1 Like
2

No offense but this “Linux is the kernel” discussion is what I really hate about the whole Linux community. If a software like Renoise “claims” to run on Linux it means that you have to have the regular “desktop”-linuxes like Mint, Ubuntu or (in my case) EndeavourOS

I never had issues installing renoise with the ./install.sh - script. Not even on my Raspi or my Steam Deck.

Concerning realtime/cpupower stuff: I wrote a complete tutorial here Arch-Linux: Best settings for realtime and low latency

3

:slight_smile:
So you might have managed to scare off all the new users
who would like to switch from competing systems.

I think that anyone who works with Linux will figure these things out for themselves.
Linux newcomers would appreciate a distribution in the form of an AppImage or another complete VM that would contain dependencies.

Or you can create a package for your distribution.
We have AUR, we have systemd, you don’t. Someone has Wayland someone X.
So dealing with these differences across distributions is quite annoying
and I’m not surprised that developers sometimes get fed up and stop developing.
You just can’t please everyone.

4

Try it on void, alpine, adélie, etc…

It has nothing to do with you having issues. I don’t think it’s fair to gatekeep software for dogmatic reasons.

My point isn’t that “it works for most people”, it is that “it is artificially and unnecessarily incompatible with some Linux distributions out there that have actual users”.

And as a personal note, if what you hate about a community is the people who are “technically correct”, maybe you should reflect as to why you hate that.

5

A flatpak distribution would actually be a good thing. Assuming it doesn’t come at the cost of the binary distribution…

6

If Renoise truly doesn’t run on environments like Alpine or void, I personally find that rather sad.
As you mentioned, offering software via formats like AppImage or Flatpak alongside tar.gz might be a good way to expand supported environments with minimal effort.

7

Otherwise, there’s the rework I offered. I can definitely make sure it works on Alpine (the install script only, the libc specifically will require some work) or void (which provides both the glibc and musl, so that would be easier).

8

I see. If modifying install.sh alone can handle different cases and expand the supported environments, that might be the best approach.
I hope your proposal gets accepted.
Because that’s one of the main reasons I haven’t switched from Arch to Alpine.

1 Like
9

My biggest concern with this is how the license is applied to the software. From this reddit post:

The full version is cryptographically signed with yr ID, so if you ever share it, they know who leaked.

It should work fine offline no problem.
10

Yes, if we register Flatpak versions in the repository, we need to address those concerns.
Also, if we make AppImage versions downloadable, we’ll likely need to build binaries for each user ID in the web backend system.
(Well, maybe it’ll just be a matter of adding relatively simple packaging steps on top of the existing build process, but I don’t know. There are probably other drawbacks to making it portable that I’m not aware of yet.)

Considering all that, if changing install.sh alone can resolve these issues, that would be truly ideal.

1 Like
11

By the way, the Renoise package in Arch’s AUR does not run install.sh.
It simply deploys according to the contents of install.sh.

I assume that such an approach is also common at Alpine.
For now, having the package manager absorb such specification differences may be a practical approach.

12

@bktn, if you have concrete ideas on how to improve the existing installation script, please share them with us so that we can update it. The current install.sh is already a community effort.

Flatpak could be nice, but it creates other problems. We tried to reduce link-time dependencies as much as possible to avoid dependency issues in general.

DEB and RPM could be useful, too, because you then wouldn’t have to run the installation script manually. This won’t cover all possible Linux dists though like the install.sh script does.

Also, the advantage of current package with the install.sh script is, that it’s optional. You can run the app directly from the downloaded folder without installing it.

libasound2t64, libc6, libc6-amd64-cross, libc6-amd64-i386-cross, libc6-amd64-x32-cross, libc6-dev, libgcc-s1, libstdc++6, libx11-6, libxau6, libxcb1, libxdmcp6, libxext6

I’m not sure where the cross deps come from. Else it’s pretty slim, compared to other Linux GUI apps?

13

Flatpak would be nice, but the license would have to be injected somehow.

Yes, that is nice, thank you. Static linking would be best, IMHO, but then again, it would probably require different versions for different environments (X vs Wayland, etc).

It would. I have zero experience with RPMs, and I don’t intend to get any. I could help with a .deb, but the same problem as with the Flatpak would arise: one would need to place the license into a well-known location (and renoise would need to support that), or manually add it to the directory renoise is in.

Nope it would not, and yes, it is very nice that one can just run the binary as-is.

ldd renoise | cut -d'>' -f2- | cut -d'(' -f1 | sed 's/[\t ]*//g' | while read libname; do
    apt-file search "$libname";
done | cut -d: -f1 | sort -u

I ran that snippet quickly the other day, and I now realized that it returns all packages names for a given dependency, not just one. Therefore the list I gave you has too many elements.

Here is the correct list: libasound2t64, libc6, libgcc-s1, libstdc++6, libx11-6, libxau6, libxcb1, libxdmcp6, libxext6.

To obtain it, one needs to run:

ldd renoise | cut -d'>' -f2- | cut -d'(' -f1 | sed 's/[\t ]*//g' | while read libname; do
    apt-file search "$libname" | grep "$libname"'$' | head -n1;
done | cut -d: -f1 | sort -u

(Essentially adding a grep and a head -n1 to filter the output of apt-file search so that it only includes files that are used by renoise, and only outputs one package per file).

As a side note, the reason why it isn’t possible to use dpkg -S to find the packages used by the files in the output of ldd is because the output of ldd does not correspond to filepaths on the filesystem, but to shared objects in the library path. So, one needs to find them on the filesystem first, to use dpkg -S, like so:

ldd renoise | cut -d'>' -f2- | cut -d'(' -f1 | sed 's/[        ]*//g' | while read libname; do
    find / -name $(basename "$libname") -exec dpkg -S {} \; 2>/dev/null
done | cut -d: -f1 | sort -u

Depends on the app, but yeah, 9 packages, 8 of which are installed with the base system (I checked against a Devuan “netinst” install with only the “Standard system utilities” selected), it isn’t bad at all. And, libasound2t64 (the missing one) is pulled whenever the user installs (non-exhaustive list) firefox, chromium, gimp, thunderbird, vlc, qemu, and of course, alsa-tools/alsa-utils.

So yeah, no, not bad, but the script should still check. :slight_smile:

14

Managing dependencies with a package manager seems reasonable.
With AUR, you must place Renoise’s *.tar.gz file in the same directory as the PKGBUILD before installing. This means, in principle, AUR “packages” are just shell scripts—they aren’t distributed as archives.
The package archive is created locally by the user following the recipe in the PKGBUILD.
Does Devuan lack a package format like Arch’s AUR or Alpine’s Abuild, where installation packages are defined solely as scripts?
If that approach isn’t feasible, might solutions using install.sh become necessary in some cases? What do you think?

15

It’s almost as if it was designed for that, right? :stuck_out_tongue:

“Well akshually…” PKGBUILD scripts are Bash (second paragraph from the top) scripts. They are supposed to be package descriptions, not scripts (second sentence, 4th word). The distinction is important because descriptions aren’t supposed to contain logic, especially not imperative logic, even if their underlying language supports it.

Devuan (because it is reusing a lot from Debian) does have a descriptive specification to assemble .deb packages. However, this isn’t meant to be working like PKGBUILD/makepkg/pacman in arch or APKBUILD/abuild/apk in alpine (or make/make install in pkgsrc), because in Debian, .deb files are supposed to be served via a repository, and it is strongly discouraged to install them as local archives (in fact, apt-get did not even handle local files for a long time, and the ability-added in 1.1-has never been documented in the man).

This means that if renoise wishes to distribute a .deb, the best way would be to set a debian repository up, with the proper cryptographic signatures, and serve renoise from there. It would be an ongoing effort, requiring dedicated ops, and not just a one-time event.

I think that providing with install.sh is the easiest option for now (as it already exists), and that making it less capricious and finicky is definitely a plus. Flatpaks (and other formats) were designed specifically for distributing binaries, so it is worth looking into that too.

Overall, I have too little insights into the inner workings of renoise and the renoise team to know how to do this best. I don’t know what build system they use, I don’t know if they use CI/CD, I don’t know if they use revision control systems (they probably do, but I don’t know which :sweat_smile:), etc.

16

Overall goal should be that:

  • installing works on most Linux systems out there
  • is not a hard thing to do

Seems the install script did its job well enough so far, so let’s fix the low-hanging fruits there before re-inventing the installation process, unless it’s so flawed that it can’t be fixed.

That said, flatpack and deb and co would be nice, but I don’t really see that they are necessary.

1 Like
17

If you have modified install.sh, you might want to share the output of git diff or diff -u.