Thank you all for your suggestions.
nix bundle sadly doesn’t work with plugins. I tried packaging
nix bundle nixpkgs#lsp-plugins, and it produced a binary that extracted some files to
/tmp and tried to run a binary that doesn’t exist. Because plugins function more as libraries than executables, I don’t think
nix bundle is the right tool for this. They also need to be placed in a location that a plugin host will look for them in, like
/usr/lib/lv2, or another place in the
LV2_PATH environment variable.
The reason flatpaks don’t work in this case is that flatpaks run everything in an isolated environment, which prevents plugin hosts from accessing plugins that aren’t in the flatpak unless they are added to the flatpak itself, which isn’t feasible given how many plugins exist (we can’t put every plugin in a flatpak), and how they’re supposed to work (plugins provide flexibility by letting you use the same plugins in any other plugin host). I would love to use flatpak, but it just isn’t right for this use.
The example on the wiki seems to get us most of the way to the result. The specific problems with the result generated by the example on the wiki that the developer pointed out to me are
- If you open the deb as a tar and look at its contents, the debian/control file has an empty “Depends:” field
- The generated deb is missing a md5sums file
The “Depends” field is set by the
debRequires argument in
pkgs.releaseTools.debBuild, so I think all we need to do is find a way to get consistent names from nixpkgs to the systems we want to build for (probably through translation), and put them in the
debRequires field, and then figure out how to generate the md5sums file and add it to the package. A lot of audio packages have similar dependencies, so I don’t think making something to translate nixpkgs names to debian names would be too much to do.
I’ve got to admit, I’m a bit out of my packaging comfort zone here. It could be that this last step of translating dependency names is just too much, but it seems so close to working.
Like I was saying, if this could work, it would be huge. Not only for nixpkgs (we would likely get a lot of new audio packages), but it would also take a significant burden off of all the maintainers who have to build these packages, as well as it would make a lot of software accessible to more users.
Any other ideas for how to do this are be appreciated. I wish we could use things like flatpak or appimage, but all of them fall short for plugins, which don’t run as executables.
Again, thank you all for your ideas so far, even if
nix bundle hasn’t panned out like we hoped