[L2Ork-dev] Packaging Purr Data as a Flatpak for Linux

Sam Thursfield ssssam at gmail.com
Thu Nov 14 17:20:07 EST 2019


Hi Jonathan,
Thanks for the feedback! I'll make the changes you recommend.

> I'd use "Purr Data." Otherwise people will confuse it with Pure Data.

My only worry is that some users will know they want "Pure Data", but
they might not think to search for "Purr Data", and think that it's
simply unavailable. I don't know exactly what our options are in
Flathub for that -- perhaps it's enough if we have the words "Pure
Data" in the description, or perhaps we'd have to do something ugly
with the name like calling it "Purr Data (fork of Pure Data)".

> What's the maintenance cost with flatpak? For example,
> what happens when a new version gets released? Do you have to do
> manually package up the new version?

The packaging manifest references a Git tag in the purr-data.git repo.
So we'd have to update the manifest to point to the new Git tag on
every new release.

(Actually, the package currently builds from my fork of purrdata.git,
in order to disable the Gem submodule. I did this because I had
problems getting the Gem repo to clone reliably. I hope that can be
resolved in future though.)

> Also, I assume flatpak does some sandboxing of apps. Does that create any
> limitations on setting real time priorities/filesystem access/etc.?

I think for the moment the sandbox is going to prevent realtime
priority, and it also prevents using JACK.  I read that in the next
Fedora cycle, there is an effort in Red Hat to make pro audio apps
work "perfectly" inside Flatpak:

> There is also a plan to have a core set of ProAudio applications available as Flatpaks for Fedora Workstation 32 tested and verified to work perfectly with Pipewire, the current apps planned to be included are Ardour, Carla, a2jmidid, Hydrogen, Qtractor and Patroneo, but if there is interested contributors joining the effort we could have even more

(from https://blogs.gnome.org/uraeus/2019/09/23/fedora-workstation-31-whats-new/)

I'm not connected with Red Hat, but hopefully we can get on board that train :-)
Sam


More information about the L2Ork-dev mailing list