Support Flatpak.

[RokeJulianLockhart]

My rationale is available at https://github.com/safing/portmaster-packaging/issues/43#issue-956312378#:~:text=It%20shall%20allow,to%20support%20this.

In case this has already been completed, please know that https://flathub.org/apps/search/blueman and https://beta.flathub.org/apps/search/blueman provide no relevant results.

I am thankful for any assistance.

[cschramm]

I have no experience with Flatpak but could imagine the sandboxing being quite a hassle for blueman.

In safing/portmaster-packaging#45 (comment) you seem to argue for Snap packaging instead. Why would you still use Flatpak then? 🤔

[RokeJulianLockhart]

@cschramm, I don't advocate for Snap instead, because the formats are not mutually exclusive. Additionally, both are advantageous and (potentially) disadvantageous in different ways:

Which is superior	Why
Snap > Flatpak	Snap supports adding a binary to $PATH to be invoked as example, whereas Flatpak necessitates flatpak run com.example.example
Snap >= Flatpak	Regarding confinement, both allow their sandbox to be significantly defeated: snap uses --classic, whereas flatpak allows assigning a specific DBus communication permission to use flatpak spwan --host.
Flatpak > Snap	Whereas the upstream snap source code solely supports one, central repository, which Canonical manages, flatpak is like any other package manager; it supports any that expose their packages in a standardized format.

For Flatpak, https://github.com/flathub provides many good examples of packaged software, all easily discoverable via http://flathub.org and http://beta.flathub.org. Alternatively, for Snap, https://github.com/snapcrafters provides the counterpart for Snap, all uploaded via CI to http://snapcraft.io.

Additionally, if you call upon the Snapcrafters (via https://forum.snapcraft.io/c/snapcrafters/23) for Snap, and users such as @TheEvilSkeleton (as demonstrated by https://github.com/TheEvilSkeleton/flatpaks) they shall be able to assist you.

These formats are not perfect: indeed, http://flatkill.org states how Flatpak's permission model is rather useless for security, despite the developers purporting that it provides effective sandboxing. However, its sandboxing capability does provide Windows/Android/macOS/i(Pad)OS-style permissions management and basic security/privacy.

Additionally, Snap is as centralized as an entirely open-source packaging platform is able to be, though this does provide tangible benefits in regard to speed, ease of maintenance, and support from Canonical and its community.

However, that is ultimately irrelevant to this request, because I solely suggest these formats to allow users to use this software easily who would alternatively be unable to, due to their distributions' package managers' repositories not including this, or including versions too old to use.

I can't determine whether it'd be a hassle, but, as previously mentioned, I believe if that you were to reach out to the Flatpak and Snap communities, few modifications to this upstream source would be necessary, if any, especially for Snap (if you ensure that you allow the package the correct permissions). Additionally, I expect that the developers there would be willing to perform much of the heavy-lifting and bothersome stuff, such as AppStream metadata (if absent).

[infirit]

I personally have zero interest in flatpak or any vendored application package format. If someone want to make one maintain it on flathub go for it.

[RokeJulianLockhart]

https://discourse.flathub.org/t/3707

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[RokeJulianLockhart]

Please reopen.

[cschramm]

I'm not personally interested in packaging blueman for Flatpak either, just like I'm not packaging blueman for any specific distribution or anything (except for the Debian package whose maintainer I happen to be). As neither of @infirit and me plans to work on this and to my understanding it does not have to be done upstream anyway (*), I don't see a value in having an open issue for it. What are your expectations?

(*) There's a lot of different packaging happening completely independent for distributions and other ecosystems like nixpksg, see https://repology.org/project/blueman/versions.

[RokeJulianLockhart]

@cschramm, that might work for me. I've not yet used Nix, but it seems interesting. However, without at least flatpak, you're missing-out on basically every non-technical user, and users of immutable OSes such as SteamOS (the Steam Deck's default) or Fedora Silverblue/Kinoite can't install it.

[cschramm]

SteamOS 3 seems to be a good example to proof your point. 👌 From what I read its default package management is indeed Flatpak (still, it's based on Arch and after "activating" its standard package manager one could just pacman -Sy blueman). I agree that it would be nice to have a blueman package at Flathub or whatever Flatpak repositories there are and make sense.

Anyway, I still don't see a value in keeping this issue open. I'm rather sure that communities like Flatpak / Flathub / SteamOS / whatever have their own trackers for packaging requests (seems like the Discourse link you posted actually is exactly that) and I cannot imagine anybody willing to build a Flatpak package to skim through our open issues and stumble upon the fact that there might be demand for packaging blueman. Personally I might give it a try at some point but definitely not by coming across a ticket drowning in other things that I once wanted to tackle. 😅