On Wed, 11 Apr 2018, Ross Gammon wrote:
I think it would be a good idea to create snaps for our priority packages, and encourage upstream to maintain them. And then if someone wants the latest and
Upstream? in most cases won't happen.
greatest, they can install it. Adding relevant snaps to our seeds )instead of the Debian package) would be a good test/goal for 18.10.
Snaps have some issues for some of our packages. I am not sure how many graphics programs have plugins and how those plugins work, in Audio programs that use ladspa, dssi, LV2 or lxvst plugins, snap instalation will simply not work. Right now we have reasonable support for plugins because we compile the hosts with the same libs as the plugins, snaps would require each application to have it's own copy of all the plugins someone might use. If the person wanted to add a plugin not included with an application they would either have to build both the host and all plugins they use or at least find out what build environment the host uses so they can use the same.
I know both gimp and blender also have plugins. At least in those cases the plugins are application specific and can become a part of that application's snap environment.
Running jackd in one snap with jackd applications from other snaps may also be a problem.
There is already a problem with audio plugins that have been incorrectly built... even if upstream does it correctly, debian tends to break it :P Audio plugins should be built static for the most part. (can't imagine how big a binary that makes when the plugin dev decides to use gtk or qt for their GUI) Two of the offenders in this are Calf plugins and Guitarix. Crashes (and other troubles) are common with both. Many devs have started creating their own GUI toolkits to combat this.
-- Len Ovens www.ovenwerks.net -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
