Possibility to port snapd/flatpak for FreeBSD

[zirias@]

incorrectly engineered libraries like Gtk that can't statically link

Quick remark on that: Qt doesn't actually make static linking as simple as it should be, but at least, it's perfectly possible (I use it a lot to create Win32 binaries, as you can't expect any sane package management on that platform ....)

 

[larshenrikoern]

Hi

I know I am late to this. But the person behind HelloSystem is the same that invented the flatpak system for Linux. And he is thinking of partly doing something like flatpak there. To make system adminstration so simple as possible. I know he will be happy to see more people helping HelloSystem out.

 

[fr0xk]

Hi partners!

I recently studied about sandboxing formats of package distribution like Flatpak and Snap, and I realized that don´t exist ports our plans, at least from the flatpak / snap community, to port snapd or flatpak for others Unix-like operating systems, after some research I undestand that the port efforts is very huge due a hard dependency of Linux kernel features like namespaces, apparmor/Selinux, and seccomp, but I thinking if is no possible adapt some of dependencys for a existing FreeBSD features like apparmor/SElinux to FreeBSD MAC using their resources for substitute a necessity of apparmor for example, or use Jails for substitute namespaces, do you think that the supposed benefits of snap / flatpak packages such as security by isolation and non-need for external dependencies justify port effort?

I personally do not use many snaps or flatpaks on my linux systems, but I like the proposal itself and would be interesting to see on BSD systems, none of the answers I got in the Linux and Snap community were very encouraging:

View attachment 5576

View attachment 5577


I do not know how viable such an idea would be, but I do not see any bad in opening the discussion .... Thanks for attention!

We, the people who work on and use FreeBSD on laptop, don't have any problems with technology made for Linux, like some developers at Red Hat think. FreeBSD is happy to adopt Red Hat's innovations if they improve the system. However, the question is: where would FreeBSD even need Flatpak?

In FreeBSD, the core system is already separate from user applications. This allows running the latest programs, like GIMP, even on older FreeBSD versions. On Linux, installing certain apps like Steam can remove critical system components (e.g., glibc), breaking the system. This issue doesn’t exist on FreeBSD or other OSes like HaikuOS, ReactOS, or RedoxOS, as they also keep the system core and user apps separate. Windows programs are self-contained, and macOS apps work similarly to AppImage. Problems Flatpak or Snap solve on Linux aren’t relevant for FreeBSD. Instead, FreeBSD and Gentoo communities are interested in cross-platform solutions like AppImage

 

[RokeJulianLockhart]

If you want to distribute your software for Linux and don't want to hope for each and every distribution to get active and provide an up-to-date package, flatpak et al actually help you. But as was said earlier, that's a bandaid. You end up distributing your own little userland with everything-but-the-kernel needed for your app. Another simpler and much older solution would be to distribute a statically-linked binary, but people seem to have forgotten how to do this?

zirias@, one of the advantages Flatpak has over a mere binary is dependency management (I know, ironic, eh) and installation support. The latter is the more fundamental improvement. If you've ever utilised Microsoft's WinGet, github.com/microsoft/winget-cli/issues/2899 demonstrates that there has been some incredible work parsing nigh unpackaged formats to provide .lnk files in CSIDL_COMMON_STARTMENU. Flatpak does the same for .desktop files in /usr/share/applications/. AppImage doesn't provide this, and that's the whole reason that projects like github.com/TheAssassin/AppImageLauncher exist. Then again, as before, we're sorta just coming back around to native packages with all of this standardisation added...