Providing a sh install script instead of OR alongside .deb installer

[mortfell]

I made a post in the Linux REAPER sub forum about the upcoming 1.6.2 release posting some new features asking people to try it out and give bug reports.
One common theme:
It seems like a large number of people don't like deb installers

I'm not totally aware of everything the deb installer is doing.
But is providing a zip or tar.gz download with an assets folder and a bash script something that could be easily done? That way people could easily change VST folders and also see what the installer is doing.

I've noticed lots of audio software is distributed like this on Linux, so just was wondering if that is something that could either replace the deb or be offered alongside it.

[baconpaul]

It is easy but a bit tedious to do.

Here’s the path

1. Write a script that creates the desired .tar.gz and desired install script.
2. Once that is written, in the surge-releases azure pipeline, call that script and make the asset
3. In the same pipeline, in the release section, create a website asset for the link to the .tar.gz like we do for a link to the .deb
4. Modify surge-synthesizer.github.io both in the production and nightly section to have links to both the deb and the .tar.gz

Alternately the users can unpack the deb themselves (like detailed here https://linux-tips.com/t/how-to-extract-deb-package/169) and then run whatever install commands they want. Perhaps if we just did step 1 above we could include that script in the deb and then people could unpack the deb. But just unpacking the deb file without installing it will show the person what it will do.

For surge to work properly the shared assets do need to be in /usr/share or ~/.share in the right place so users should exercise caution, but surge will give an error message if that’s broken.

Finally: I don’t plan on doing this before 1.6.2 and it’s all a bit tricky in the pipelines. So while I would consider a pull request I’d invite the folks who did it to be super careful and consider the smallest change possible approach.

[mortfell]

Ok cool, if anyone is like "why is it only deb" I'll direct them to this thread, and they can comment if they want it.

Maybe someone will offer to do the scripting and do a pull request 🤔

[baconpaul]

That’d be great

Or at least do a really great job on step 1. That is: make a script like the install_linux/make_deb.sh which takes the same arguments (SURGE_VERSION and stuff) called install_linux/make_tgz.sh, which makes a tgz that is acceptable to the part of the community that doesn’t like deb, get it working, and then one of us could pipeline it if they don’t know the pipeline stuff.

I mean I could make up some nonsense for what I think a linux tar gz installer should look like, but it would mostly be echo “macOS is Unix too you know!”

[mortfell]

Yeah I think this could be a useful thing... I've always used debian based distros, so it's hard for me to care too much about it, but just thought I would start an issue as I know some people care.

[baconpaul]

Yeah and the people who care are probably also people who have the capacity to fix it. So lets just leave the issue open and see if someone picks it up.

[baconpaul]

Also linking to the closed #365

[jpcima]

It's a thing I was asked to implement once, so I'll mention open build service.
It's a free construction service by openSUSE which outputs all the DEB and RPM of major distributions.
Nowadays, there exist ways to interact it with Github, which personally I never tried yet.

[baconpaul]

Neat! That seems to provide the same sort of stuff the azure pipelines provide us but doesn’t have a Mac or Windows build as far as I can see

I think the real problem we are cracking here though is: what’s an appropriate asset to build at the end of our pipeline? Right now we make a deb file. How do most free synths distribute their binary?

[jpcima]

A zip together with a deb is fine, although somewhat redundant.
In the domain of audio plugins, flatpak is unfortunately not a possible solution.

The problem faced for binaries to be universal, it is the shared library incompatibility; for instance, a targeted libc too recent, or a different version of something (eg. xcb problem).

For a maximum compatibility, (1) build on the oldest targeted linux, (2) favor static linking of dependencies.

(For the record, I was contacted by the Linuxsynths.com author, to recreate the Surge binaries compatible with Debian Stretch, as they suffer the libxcb problem)

[baconpaul]

Yup. Speaking as a life-long advocate for and contributor to open source, the shared library problem is exactly the kind of problem that open source will never fix, and which will greatly hamper the community. The MacOS solution (have a version controlled by a central source and build abi compatability into the dev tools) is lovely and un-doable in linux.

So with the xcb problem I just don’t know what to do

Statically build xcb in our pipeline, and statically link it? That adds a lot of time to every build
Pick one and have some people left out (our current choice)? That is a bummer
Do two builds?

I think (but am not sure) that the solution may be to dump premake and use a more standard tool so people can do more standard builds themselves. Like remember how gentoo would build everything form source? But even then we have distro tie in.

So for now, I’m going to do nothing, but am happy to consider any ideas or efforts given a couple of constraints

1: The CI pipeline needs to continue to work all platforms
2: The official builds we post to the website need to come out of there
3: Everything needs to be scripted and automated

given those basic ideas, I’m all ears for what to do.

[trebmuh]

I think (but am not sure) that the solution may be to dump premake and use a more standard tool so people can do more standard builds themselves

👍

[baconpaul]

@trebmuh we have a cmake build for the headless component so have already tiptoed down that path.

Someone needs to take all the things premake does for the plugin proper and move it to the cmake file. That something in your expertise? I’m not really a cmake guru.

I would be happy, post the 1.6.2 release, to dump the premake dependency if someone can get cmake working mac, win and lin building the 32 and 64 bit AU VST2 VST3 and LV2!

[baconpaul]

Just read the original post on the reaper forum

We should tell the user that

1. They can unpack the deb by hand and see what's in it
2. They need the dependencies and
3. The .so doesn't work alone; it needs the assets in share as placed by the deb.

I would do that but for some reason my account can't post to the forums

[jpcima]

Statically build xcb in our pipeline, and statically link it? That adds a lot of time to every build

A static library is provided in libxcb-util-dev, it's not needed to remake it.
The problem is to express the commands to make the build system use it.

I have a decent experience with cmake, I can surely examine how to make this transition.

[baconpaul]

Wonderful. Right now the premake just uses cflags :

surge/premake5.lua

Line 306 in 102998c

"-Wno-unused-variable",

Lib-xcb-util-dev is already in our pipeline

So a static link of xcb may be an easy change?

[jpcima]

Not entirely, it needs to think of the full implications of doing so; and unfortunately it's really delicate.
For example, cairo works with a xcb surface backend, so cairo is also a user of xcb.
If xcb is static linked, then cairo also must be static linked; or it's a potential incompatible situation, where vstgui uses static xcb, but dynamic cairo will use dynamic xcb.

I think, it must not be too hard to provide the CMake, I will add it in order to help the packaging.

[trebmuh]

Someone needs to take all the things premake does for the plugin proper and move it to the cmake file. That something in your expertise? I’m not really a cmake guru.

Unfortunately, no.

My background position is I've tried a few days ago to build a deb package for LibraZiK-2, but then, the premake5 need avoided me to do so since it's not yet in the Debian repositories (LZK repo is build on top of Debian repo).

So it'd be wonderful (from my little selfish auto-focused point of view) if a switch to cmake could happen sometime since it'd make my purpose much easier to achieve.

[jpcima]

@trebmuh allow me to suggest a really dumb solution,
could you pre-generate build files on the machine, the surge-*.make, store them and just copy them identical into your working directory for packaging?
From what I see, these makefiles appear to be perfectly portable.

[trebmuh]

definitely, it is a good workaround for the times being

[baconpaul]

Ok cool. This is all stuff where you guys know better than me so I’m just going to leave it to your expertise. Still plan on shipping 1.6.2 as is with premake I’m next 7 days or so but we can adjust after that

And thank you!!

[baconpaul]

Hey @jpcima just kicking this issue quickly since I just today moved linux and macOS so they no longer use premake and are 100% cmake (+ ancillary scripts for a couple of things) to build.

Dunno if this lets us solve the static vs dynamic xcbutil but wanted to tag it.

[gnac]

@baconpaul It looks like the surge-xt-distribution build accomplishes at least some of this. It doesn't, at the moment, include the assets, but that could be added. It also won't help with library incompatibilities on all platforms, but its a start.

[baconpaul]

Ha yeah this issue was written before we were even on cmake!

so with xt I just run the distro target and upload what it makes so we can go ahead and make multiple flavors of download easily! Would welcome things which make life easier for linux folks

[gnac]

Added tarball creation to make_deb.sh in PR #4525

[baconpaul]

All in the pipelines. Closing this.