packaging gripe of tonight: JUCE. I know many people in the open source pro audio ecosystem such as @falktx have their own issues with JUCE, but from a distro packagers perspective it's an absolute nightmare. JUCE forces a copy of itself to be bundled in every single project that uses it, with no way to unbundle it. Debian installs it as sources, but that's still not a very good solution. Additionally, JUCE bundles many third-party libraries itself and the developers have refused a request to allow unbundling them (github.com/juce-framework/JUCE). Once again I do understand how bundling dependencies can be tempting as a developer (especially with libraries that have brittle ABIs or frequently break their API), but it causes infinitely more pain for downstreams who have to maintain patchsets. If you want more information on the subject of why bundled dependencies are a no-go in distro packaging, read these pages: fedoraproject.org/wiki/Bundled, wiki.gentoo.org/wiki/Why_not_b

Follow

@vimproved this is simple, they do not support the kind of packaging you are attempting to do.

packaging juce is a bad idea, their API breaks quite frequently and so you would need to package juce separately for every minor release.

vital[ium] is an example of a plugin where it renders correctly in juce6.0, but gets very messed up in juce6.1. and that version of juce is not maintained anymore, they are already moving on with juce 7.x and soon juce 8.

@falktx
Yep, it's just unfortunate since so many otherwise very high quality plugins use it

Sign in to participate in the conversation
falkTX Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!