Reaper Snap Package

[lucianodato]

Hello everybody! I'm attempting to build a snap package for reaper. What do you think would be correct, packaging the prebuilt binary or building libswell from source? I'm looking at the AUR script and they are compiling it. Not sure what to do. Anyways, here is a rough yaml script that barely works in my system: https://github.com/lucianodato/reaper-snap

Do you consider this useful?
Edit: It seems that this cannot be done without authorization. So the repository was removed. Sorry for the inconvenience.

[lilith]

What's a snap package? I know snapchat, but ...

[lucianodato]

hmm do you have permissions to redistribute their binaries?

1. DO NOT REDISTRIBUTE ANYTHING FROM THIS WEBSITE

(from LANDOLEET)

Hmmm thanks falktx I didn't pay attention to that. I will remove it now. Will have to ask I guess.

[lucianodato]

What's a snap package? I know snapchat, but ...

https://en.wikipedia.org/wiki/Snappy_(package_manager)
There you go. It's quite convenient package system for any distribution and it's made by canonical.

I'm interested to know what do you think of it falktx? Have you looked at it?

[lucianodato]

Anyways I ended up doing a bash script for myself that installs it with the desktop integration, SWS extensions and the reapack. Job done .

[chaocrator]

just 2 cents for those who are curious about all this snap packaging thing.

snap packaging system is advertised as the deliverance from distro-specific dependencies hell, but for some reason no one talks about its drawbacks.
snap packaging potentially means not only significant disk space overhead (disks are cheap nowadays, so nobody cares), but a huge RAM usage overhead too, since it can quite easily end up with several copies of the same libraries loaded into the RAM when the software is running, instead of just one in a classic dependency-hell-based distro.
and it's not difficult to understand that the software vendors WILL proliferate their excessive copies of libraries instead of distro-specific optimization. because they care about their human-hours a lot more than end users.

in particular, that's the exact reason why desktop versions of popular mobile messenders are such RAM hogs — because they tend to have their own copies of all GUI-related libraries.

actually, there are some cases when this kind of packaging is really a deliverance. but in my opinion, those cases are about server software, where software updates must not break services availability, and where excessive RAM usage is not a problem, especially in the clouds where RAM can be expanded on the fly.

[lucianodato]

What you are pointing is true but on newer systems the benefits outweigh the cons.

[CrocoDuck]

What you are pointing is true but on newer systems the benefits outweigh the cons.

Trough my (very limited) programming and packaging experience, I think I disagree. I think I came to the conclusion that optimization is very very important. Many DE maintainers don't care about it properly under the assumption that modern machines are more than enough, but this yields to DEs that are really under-performing and very little portable to other architectures, say ARM. Self contained application bundles and poor optimization are what make MS Office to need 1 minute to boot up on computers that would have terrified any computer scientist of 20 years ago.

Now, one Linux strength resides in its portability, and I believe a fraction of it stems from the way software is installed and the whole systems kept more efficient, even for binary based distributions. When one thinks about the fact that we have good package managers, dependency hell doesn't really seem a hell after all: everything is taken care automatically. I might be bias by how easy it is to create packages under Arch though, and by how straightforward pacman is to use.

As for self contained packages, I can totally see myself using even docker containers for massive scientific software, for example, like TensorFlow, AcouSTO or something like that, to deploy easily on a virtual cluster and have computation delivered right away, without having to configure the hell out of those. Huge parallelization will eat out the non optimality of using a container. But I am not a huge fun of them in desktop environments: if I have the time to install them the ordinary way, I prefer that.

[lucianodato]

What you are pointing is true but on newer systems the benefits outweigh the cons.

Trough my (very limited) programming and packaging experience, I think I disagree. I think I came to the conclusion that optimization is very very important. Many DE maintainers don't care about it properly under the assumption that modern machines are more than enough, but this yields to DEs that are really under-performing and very little portable to other architectures, say ARM. Self contained application bundles and poor optimization are what make MS Office to need 1 minute to boot up on computers that would have terrified any computer scientist of 20 years ago.

Now, one Linux strength resides in its portability, and I believe a fraction of it stems from the way software is installed and the whole systems kept more efficient, even for binary based distributions. When one thinks about the fact that we have good package managers, dependency hell doesn't really seem a hell after all: everything is taken care automatically. I might be bias by how easy it is to create packages under Arch though, and by how straightforward pacman is to use.

As for self contained packages, I can totally see myself using even docker containers for massive scientific software, for example, like TensorFlow, AcouSTO or something like that, to deploy easily on a virtual cluster and have computation delivered right away, without having to configure the hell out of those. Huge parallelization will eat out the non optimality of using a container. But I am not a huge fun of them in desktop environments: if I have the time to install them the ordinary way, I prefer that.

Fair enough. The main benefit is that using snaps or flatpaks is that you are covering all distribution at once. Plus isolation is a big plus on the server side. And making these packages involves a simple yaml file and with a quite intuitive syntax. And from what I've heard at least in snaps there are socket mechanisms to avoid cluttering RAM (ffmpeg snap weights 20 Mb). It's not that much more RAM in the majority of cases but there are exceptions of course. Making a snap for Reaper doesn't require much dependencies so seems reasonable. Anyways I ended up doing a script similar to the AUR PKGBUILD.

[CrocoDuck]

FThe main benefit is that using snaps or flatpaks is that you are covering all distribution at once.

That's perhaps one of the biggest pros. Does it work for distributing things like plugins, by the way? I remember you asked about it in another thread.

And from what I've heard at least in snaps there are socket mechanisms to avoid cluttering RAM (ffmpeg snap weights 20 Mb).

That's interesting: if technology can find a way to kill both birds (ease of distribution and efficiency) with one stone then we are sorted.

[Garrick]

hmm do you have permissions to redistribute their binaries?

1. DO NOT REDISTRIBUTE ANYTHING FROM THIS WEBSITE

(from LANDOLEET)

You are right but I wonder if package managers like snap, flatpak and whatnot, are what cockos had in mind.
Someone should ask them.

I wonder if the maintainer of the aur package/script had the blessing.

I was wondering earlier about reaper as an appimage but having installed the latest (5.94), the installer is crazy easy.
Gives the option to install to /opt or make an opt dir in your home folder, or what ever folder you like, an sorts out shortcut.

[lucianodato]

With their script we can consider this as solved yeah