Standardized set of LADSPA plugins

[jasp00]

Debian has a bug report about reusing the LADSPA plugins in LMMS.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758888#25

The issue is whether we could get a compromise from LMMS developers about maintaining a stable set of LADSPA plugins with a proper namespace, such as caps-lmms instead of caps, so that they can be reused without conflict with third-party plugins. I could help writing an upgrade_*() method, although I believe a manual upgrade is more appropriate.

[tresf]

I believe a manual upgrade is more appropriate.

We don't have a prompt to the user to fix broken plugins currently, so this "manual upgrade" proposal would be to edit a compressed XML file, which we'd never tolerate.

Can you please explain the existing "conflict" that you speak of?

[tresf]

I'd also like to add, there's nothing lmms-specfic about the LADPSA plugins we ship other than the install location and the potential outdated nature of them. Redundant libraries happen all the time and Linux seems to be the only platform that gets upset about them. Can you explain the problem in detail please?

[jasp00]

Can you please explain the existing "conflict" that you speak of?

We would like to share the LADSPA plugins from LMMS. For instance, that would mean to install caps.so in /usr/lib//ladspa, which would conflict with our package caps (that should use the same location). We also have the packages calf-plugins, cmt, swh-plugins and tap-plugins.

Redundant libraries happen all the time and Linux seems to be the only platform that gets upset about them. Can you explain the problem in detail please?

The main justification is security updates. In general, when you want to debug or modify software, it becomes much harder if there are multiple copies of the code (redundant libraries, static linking, forked libraries). There are penalties in size (disk usage, network download) and build time. This problem is more frequent in Linux because of its open-source nature: everyone modifies the software of everyone.

[tresf]

We would like to share the LADSPA plugins from LMMS. For instance, that would mean to install caps.so in /usr/lib//ladspa, which would conflict with our package caps (that should use the same location). We also have the packages calf-plugins, cmt, swh-plugins and tap-plugins.

Sure, but why? So that you don't have to add an arbitrary search location to your LADSPA path? What is the advantage of having it in /usr/lib over the app-specific location?

The main justification is security updates. In general, when you want to debug or modify software, it becomes much harder if there are multiple copies of the code (redundant libraries, static linking, forked libraries).

Again, any other platform just lives with this. On Windows, if you are running Pidgin and you're running Gimp, updating one doesn't mess with the GTK used for the other. This is quite extreme though, what you're talking about is about 7MB of .so files.

Another example is that Node.js uses the Google V8 JavaScript engine, but if you install the latest Node.js on Linux, it doesn't attempt to remove redundancies and use Chromium's libraries to do so.

Furthermore, from a system perspective, I think it's even more messy to have caps.so along side caps-lmms.so. Furthermore, what is the advantage of having it there? Now more applications coded to look there will rely on lmms-specific versions of the LADSPA plugins, which means more non-LMMS projects can have the potential to crash when LMMS is removed or incompatible.

And to add insult to injury, our Debian LMMS packages aren't even being maintained, so I feel like we're splitting hairs on a packaging process that has no one owning it (thanks to KXStudio, we at least have something to install the latest on Debian distros).

If I'm off the mark, please correct me.

Furthermore, if you want to take the time to prefix all LMMS-shipped-LADSPA plugins and write the compat code to read them back in with old project versions, please feel free to do so, but I'm still a bit confused on the advantage of this work effort. 👍

[jasp00]

I see that this is related to #2366.

Sure, but why? So that you don't have to add an arbitrary search location to your LADSPA path? What is the advantage of having it in /usr/lib over the app-specific location?

We do not manipulate LADSPA_PATH and LADSPA applications already look in /usr/lib. Installing plugins in /usr/lib is easier for the user if plugins are to be reused.

On Windows, if you are running Pidgin and you're running Gimp, updating one doesn't mess with the GTK used for the other.

If you fix GTK, you have to update Pidgin and Gimp instead of GTK only.

Furthermore, from a system perspective, I think it's even more messy to have caps.so along side caps-lmms.so. Furthermore, what is the advantage of having it there? Now more applications coded to look there will rely on lmms-specific versions of the LADSPA plugins, which means more non-LMMS projects can have the potential to crash when LMMS is removed or incompatible.

The advantage is to have a stable set of plugins that will not change their names or behavior. That is why I am asking for a compromise. For instance, that you will stick with CAPS 0.4 and maintain it instead of a possible migration to CAPS 0.9.

And to add insult to injury, our Debian LMMS packages aren't even being maintained,

We are trying to fix that.

we at least have something to install the latest on Debian distros).

We have the 1.1.3 release. Debian focuses on stability; the most we could do is to have 1.2.0-RC1 in experimental (would that be okay?).

[tresf]

We have the 1.1.3 release.

Great.

The advantage is to have a stable set of plugins that will not change their names or behavior. That is why I am asking for a compromise.

Well in that case, make the upstream version a required lib.

If you fix GTK, you have to update Pidgin and Gimp instead of GTK only.

Right, this is how most large application bundles happen, except in Linux. When specific versions of shared system libraries become mutual hard-dependencies, it's just a headache for all involved.

For example, we could make Homebrew (or MacPorts) a requirement of LMMS on Mac and use the Qt version that's installed rather than bundling it, but most people installing LMMS on Mac don't have Qt installed and they may not even have Homebrew. Same goes for LMMS on Windows. So the idea of shipping our own binaries isn't a new concept and I think we have a use-case that makes quite a bit of sense. Disk space is cheap and the bandwidth for our binary builds is kindly provided by some good, reliable CDNs.

That said, I don't think we'll have any problems with the prefix proposal. The backwards compat is going to be some work.

But I'm somewhat inclined to ask you to instead consider tackling this at packaging time, since the other platforms won't necessarily benefit from this change. For example, our Mac installer already has to do some package-time linking to get things in the right place. Not sure what tools exist for Linux for this very same purpose, but assuming they do, you can provide a symlink in the old location for compat purposes. Just an idea...

At the end of the day, I agree /usr/lib/caps.so is a bad idea for us to install and /usr/lib/lmms-caps.so is a slightly better idea, but I don't know if this change warrants every LADSPA namespace gets changed. Prefixing all libraries with lmms- is just gross from a packaging perspective... at least when NOT installing to a shared location.

[tresf]

jasp00 closed this 2 minutes ago

Was this done intentionally?

[jasp00]

Yes. We were done, right?