How to build an application for multiple Linux distributions from a single source

[Audiojunkie]

I've been thinking about this topic for a while, and I'd like to open a discussion about it. I've researched the various distributions and their repositories and I have determined that when it comes to Linux plugins, effects, and instruments, there are two main families of distros that contain the lion's share of the music applications: The Debian and Arch families of distros. The Arch family, with the Arch packages and also AUR probably have the most and best supported music making applications. The Debian family (including Ubuntu, Mint, etc) has the KXStudios repository, which makes up the lion's share of available music making apps for that family of distros. The other major families of Linux distros (ie Fedora, Red Hat, SuSE, etc) seem to contain smaller numbers of available music applications in their repositories.

When it comes to commercial works or closed source and freeware applications, the Debian family (probably due to popularity) seems to get the most support and apps. Almost universally, when a single binary package is supported, it is a Deb. Rarely, you will find support for more linux binaries, but it does happen. The problem with all of this is that, as is commonly stated, there is no "Best Distro". There is only the best distro for you. Each distribution is tailored to a specific target audience, and of the 200+ active distros out there, developers are not packaging these apps for your particular distribution.

When it comes to commercial applications, the reason is usually a matter of business--choosing distribution method that will reach the highest number of potential customers with the least amount of work. I can't fault that. I don't fault the many various distributions that target specific audiences either. So, the problem comes down to this: How to build an application for multiple Linux distributions from a single source--especially for commercial and closed source developers.

For open source development, at its most basic level, there is Git, SourceForge, etc. People can custom-build from source using Make without too much effort. However, commercial developers don't want to open their source, which means that if you want to use a commercial Linux application, you are probably stuck with a .Deb compiled specifically for Ubuntu. If you are an Arch based distro user, you will likely not have any commercial apps available to you. This is the problem I'd like to find the best method to solve. I truly believe that a lot of developers (maybe not on THIS site, but on other sites--like KVR, for instance) are trying to support Linux, but truly know little about this environment. They compile their app on Ubuntu and call it "experimental" or "beta" and do not guarantee it works--Try before you buy, they warn. if you need something other than .Deb, you're out of luck.

But it doesn't have to be this way. I'd be willing to bet that many developers are unaware of the various tools that are available for making their job easier. For instance, the Linux Standard Base has been set up to reduce differences between various distributions:

http://www.linuxfoundation.org/collabor ... roups/lsb/

http://en.wikipedia.org/wiki/Linux_Standard_Base

Projects for easily creating various binaries from a single source (like the Open Build Service) are now available:

https://www.ibm.com/support/pages/how-b ... le-source/

https://openbuildservice.org/

https://en.wikipedia.org/wiki/Open_Build_Service

These things that I mention are only 2 possible solutions out of what I suspect are many ways of going about this. In the end, we all benefit if the widest number of distributions contain the widest number of available music apps. Thoughts? Comments?

Let's discuss!

[d.healey]

commercial developers don't want to open their source,

Don't mix commercial and proprietary. There are plenty of proprietary plugins that are non-commercial and (maybe not so many) commercial plugins that are not proprietary.

If it's proprietary then I'm not interested, if it's free software then I can build it from source so I don't have an issue if my distro doesn't have a pre-built binary, although I'm a Debian guy so not such an issue for me.

Does a .so file built on Debian not run on Arch? I thought they did...

[Gps]

LMMS has an appimage file for download.

This works on probably every Distro, but I can confirm it works on:

Ubuntu, Mint, Arch, OpenSUSE, Fedora and Debian

Set right to executable after download, double click the file to start LMMS.

Not sure if this is what you mean though.

https://lmms.io/download#linux

[Audiojunkie]

commercial developers don't want to open their source,

Don't mix commercial and proprietary. There are plenty of proprietary plugins that are non-commercial and (maybe not so many) commercial plugins that are not proprietary.

If it's proprietary then I'm not interested, if it's free software then I can build it from source so I don't have an issue if my distro doesn't have a pre-built binary, although I'm a Debian guy so not such an issue for me.

Does a .so file built on Debian not run on Arch? I thought they did...

An .SO file should work in the isolated case of self-contained plugins, but that's not usually how the files are being distributed--they are coming in .DEB packages.

EDIT: Isn't .SO just a VST2 thing? I think VST3 was much more involved? What about apps that aren't plugins?

[Audiojunkie]

LMMS has an appimage file for download.

This works on probably every Distro, but I can confirm it works on:

Ubuntu, Mint, Arch, OpenSUSE, Fedora and Debian

Set right to executable after download, double click the file to start LMMS.

Not sure if this is what you mean though.

https://lmms.io/download#linux

Appimage, Flatpak, and Snaps are all great for multiple Linux distributions that work in a single, standalone, sandboxed environment. This won't work, however, for plugins, effects, and instruments because of the very nature of the sandboxing.

[d.healey]

EDIT: Isn't .SO just a VST2 thing? I think VST3 was much more involved? What about apps that aren't plugins?

I think a VST3 should load the same as a .so. Standalone apps are a different matter.

[Kott]

The other major families of Linux distros (ie Fedora, Red Hat, SuSE, etc) seem to contain smaller numbers of available music applications in their repositories.

It might be truth for the "main" repo. With user's repositories in copr and OBS those distros can compare or surpass Arch and Debian/Ubuntu + KXStudio.

LSB is "dead", no one follows it. Anyway if someone tries to easy cover most of distros - just make packages for Ubuntu 18 LTS and CentOS 7.

Open Build Server is great and underrated thing. For opensource app you can just use build.opensuse.org. Yes it needs the knowledge of making rpm, deb AppImage, PKGBUILD etc.
For closed apps you can ignite your own on-site instance. Commercial devs counts their money/time thus barely one wants to spend time for learning packaging and devops-ing with OBS.

[Kott]

Does a .so file built on Debian not run on Arch? I thought they did...

Mess with libcurl-gnutls.so (Debian/Ubuntu) and libcurl.so (All of the other world) is most common thing.

[Audiojunkie]

The other major families of Linux distros (ie Fedora, Red Hat, SuSE, etc) seem to contain smaller numbers of available music applications in their repositories.

It might be truth for the "main" repo. With user's repositories in copr and OBS those distros can compare or surpass Arch and Debian/Ubuntu + KXStudio.

LSB is "dead", no one follows it. Anyway if someone tries to easy cover most of distros - just make packages for Ubuntu 18 LTS and CentOS 7.

Open Build Server is great and underrated thing. For opensource app you can just use build.opensuse.org. Yes it needs the knowledge of making rpm, deb AppImage, PKGBUILD etc.
For closed apps you can ignite your own on-site instance. Commercial devs counts their money/time thus barely one wants to spend time for learning packaging and devops-ing with OBS.

Interesting! I wasn't aware of the COPR for Fedora. However, I was referring specifically to "Music applications", and the COPR doesn't appear to come anywhere close to what Arch's package repository and the AUR have. Mind you, I'm referring specifically to Music applications.

The OBS interests me. It seems like the best (and possibly easiest) way for a developer to create and support multiple binaries from a single source. That's why I've been exploring it.

[Kott]

Interesting! I wasn't aware of the COPR for Fedora. However, I was referring specifically to "Music applications", and the COPR doesn't appear to come anywhere close to what Arch's package repository and the AUR have. Mind you, I'm referring specifically to Music applications.

This is one of Fedora audio repo https://github.com/ycollet/fedora-spec
This is openSUSE https://build.opensuse.org/project/show ... italia:daw

I didn't compare the number of packages in aboves with Arch, Debian, KXStudio. It may be interesting challenge.

The OBS interests me. It seems like the best (and possibly easiest) way for a developer to create and support multiple binaries from a single source. That's why I've been exploring it.

I have experience with build.opensuse.org so please ask any question on it.

[Audiojunkie]

Interesting! I wasn't aware of the COPR for Fedora. However, I was referring specifically to "Music applications", and the COPR doesn't appear to come anywhere close to what Arch's package repository and the AUR have. Mind you, I'm referring specifically to Music applications.

This is one of Fedora audio repo https://github.com/ycollet/fedora-spec
This is openSUSE https://build.opensuse.org/project/show ... italia:daw

I didn't compare the number of packages in aboves with Arch, Debian, KXStudio. It may be interesting challenge.

The OBS interests me. It seems like the best (and possibly easiest) way for a developer to create and support multiple binaries from a single source. That's why I've been exploring it.

I have experience with build.opensuse.org so please ask any question on it.

Cool! Is there anything that you know of that is better than the OBS for multi-distro binary compilation from a single source?

[Audiojunkie]

I discussed with a developer tonight how he was going about it. In his case, he compiled on Mint, and packaged the .SO files into a zip file. He tested the .SO files on the Debian and Arch families.

Uhe and Cockos use distro agnostic methods as well.

It seems strange to me that .DEB files would be used instead of a zip file with the .SOs files. It almost seems to be limiting.

I’ve now read two places where people are opening DEB files. How does one achieve this? What tool is used to u archive or view DEB files?

[Kott]

What tool is used to u archive or view DEB files?

Midnight Commander, or ar, or alien -r for convert to rpm

[Kott]

Cool! Is there anything that you know of that is better than the OBS for multi-distro binary compilation from a single source?

I have OBS skills only. We can summon @ycollette for telling about copr.
What we have in OBS:

[Audiojunkie]

Cool! Is there anything that you know of that is better than the OBS for multi-distro binary compilation from a single source?

I have OBS skills only. We can summon @ycollette for telling about copr.
What we have in OBS:

That is an incredible list of distributions that are possible from a single source!!