[Antonio Ospite] > Hi Petter, > > about the duplication, the proper solution would be to coordinate > with the other Debian maintainers, which can be hard.
Well, it would not be that hard, as we can always fall back to just install plugin <foo> as <foo>-lmms if we are unable to reach the maintainer currently installing <foo>. > The Debian alternatives system could provide a workaround, but I am no > expert about it. We could use diverts too, but neither seem like a better idea than coordination and renaming. > Regarding the plugin path, my use case is to use the vocoder plugin > provided by lmms with GStreamer (see http://ao2.it/109), and the ladspa > element in GStreamer seems to be looking for plugins in these paths: > > /usr/lib/ladspa > /usr/local/lib/ladspa > /usr/lib/x86_64-linux-gnu/ladspa > > So using /usr/lib/x86_64-linux-gnu/ladspa would work for me. I agree that /usr/lib/<arch-triplet>/ladspa is a good idea. Are there other programs using that location? I guess someone with time and contacts should get in touch with the ladspa community and try to get acceptance for the idea there, to get it in the official specification or something. > To make this more formal, maybe Debian itself could specify that > packages providing/using LADSPA plugins should use the multi-arch > path, but I do not see myself involved in that. Can you write a proposal explaining how you believe Debian packages using LADSPA should behave regarding directory locations, and put it in wiki.debian.org somewhere? It would provide a good starting point for solving this issue globally, both as a reference text and as a discussion starter. It is probably a good idea to have non-Debian linux distributions in mind too. -- Happy hacking Petter Reinholdtsen