# Possibility to port snapd/flatpak for FreeBSD



## bledyzer (Nov 25, 2018)

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 communitys were very encouraging:











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


----------



## NewGuy (Nov 30, 2018)

I think the bigger issue here is that even if you did manage to port Flatpak or Snapd to FreeBSD, the packages wouldn't necessarily run because their libraries and other dependencies are expecting a modern Linux environment. The FreeBSD compatibility layer for Linux isn't going to work with a lot of existing Flatpak/Snap packages.

Another problem, at least with Snapd, is that it requires systemd. Linux distros without systemd cannot run Snaps. And, as pointed out above, Flatpak requires namespaces, which isn't available.

So porting these frameworks is going to be a huge undertaking that will require a huge amount of work in the kernel and low-level libraries and in many cases will not result in a working package.


----------



## Beastie7 (Nov 30, 2018)

The FreeBSD Capsicum framework is used for sandboxing and compartmentalizing file descriptor rights for applications. 

As far as automatic deployment of sandboxed applications, this can be somehow tied to pkg, but I think the apps themselves would need to incorporate the 'Capability mode' APIs in FreeBSD. I'm not sure though.

Flatpaks/Snaps really have no place on a FreeBSD system. It's a bandaid to a more fundamental problem in Linux IMO.


----------



## ShelLuser (Nov 30, 2018)

Other than the above I _seriously_ fail to understand the extra gained value here. In my opinion there is absolutely 0 value to gain from porting this stuff over.

Do you need sandboxing for your packages? Get a Jail. Remember: FreeBSD is NOT Linux, ergo it often has different solutions for the same problems.

Best of all is that this solution is available 'out of the box' (no 3rd party software required) and the only possible strain is storage capacity. And even that can be circumvented with some smart nullfs mounts.


----------



## Vull (Nov 30, 2018)

I don't know what it means, but every FreeBSD11.2-RELEASE-p4 system I've installed this month seems to have an empty /.snap directory in the root directory, which came as part of the install, and would like to know why. It's not a big worry but it is a bit of a concern.


```
$ ls -la /.snap
total 16
drwxrwxr-x   2 root  operator   512 Nov 15 14:55 .
drwxr-xr-x  19 root  wheel     1024 Nov 30 16:45 ..
$ freebsd-version
11.2-RELEASE-p4
$
```


----------



## Phishfry (Dec 1, 2018)

It's for UFS filesystem snapshots, dump(8) and backround fsck(8).
https://wiki.freebsd.org/ExampleUfsSnapshots
https://www.freebsd.org/doc/handbook/snapshots.html

Polytropon is a mailing list hero:
https://lists.freebsd.org/pipermail/freebsd-questions/2012-January/237296.html


----------



## Vull (Dec 1, 2018)

I'm relieved to learn that this comes from snapshots and not snap. I had seen snap residue in the / directory and root account PATH environment variable previously, not on FreeBSD but rather on Ubuntu and/or Linux Mint systems. One of the things that led me away from those systems was realizing that there were a lot of non-standard, seemingly hidden things going on behind the scenes which I didn't understand, and didn't really have the time or inclination to research. For instance I don't like administering a *nix-style system where I'm not allowed to know the root password. It reminds me too much of working in Windows-world. My thanks to you and to Polytropon for this information.


----------



## ShelLuser (Dec 1, 2018)

Vull said:


> I don't know what it means, but every FreeBSD11.2-RELEASE-p4 system I've installed this month seems to have an empty /.snap directory in the root directory


Your question has _nothing_ to do with that of the OP, please don't hijack a thread like this. It is highly impolite and only diverts the attention away from the actual problem at hand: porting snapd/flatpack to FreeBSD.

Next time please start a new thread and show some consideration.


----------



## Vull (Dec 1, 2018)

Please accept my apologies. Although I was clearly mistaken I did think it might be related. Exiting thread now & have a good evening.


----------



## cabriofahrer (Jul 16, 2022)

I bumped into this thread by chance today and it made me remember the old PBI Packages of PC-BSD. Many years ago I checked it out on my FreeBSD system and it was great, because I could install OpenOffice as a PBI, which did not exist as a FreeBSD package back then. So my first thought was, why not recover PBI instead of trying to port snapd / flatpack? But then I found this here:









						PC-BSD PBI, what reasons made it to be scrapped?
					

What are the detailed specific technical/organizational reasons that the PC-BSD team faced that ultimately lead them to scrap PBI and return to ports?  Was because of the difficulties compiling and




					unix.stackexchange.com
				




The long answer to this question is very well explained there. So the conclusion that I draw from this is that the best thing would be to port desired software to pkg.


----------



## zirias@ (Jul 16, 2022)

Yes, please forget about all these things immediately!

There's nothing wrong with wanting an application to run in some isolated environment, but you can easily achieve that yourself, putting it (and its dependencies) in a jail.

The real reason for stuff like flatpak is a different one. It kind of reminds me of the situation on Windows, that always suffered from "DLL hell", so nowadays, software binaries are distributed with all their dependencies bundled.

Software has dependencies, and the root of all problems with that is: different versions might be incompatible. For shared libraries, *nix systems already have a simple and effective solution: libraries have versioned SONAMEs, the version must change on breaking changes, so you can have multiple versions of the same lib installed and the dynamic linker is able to find the correct one. For other dependencies, similar solutions are possible, like e.g. just versioning the names of the binaries. This is also done on FreeBSD, e.g. with python.

But now have a look at Linux world: There are myriads of distributions, and the problem gets worse by them using different, potentially incompatible, compilers, standard C libs, and so on. 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. 

On FreeBSD, you have a defined base system (including compiler, c lib, etc...). Everyone uses the same, no incompatibilities to expect here. The ports tree is also the same for everyone, if a software needs another library or a newer version of it, update/add the ports. There's no sane reason for such monsters on FreeBSD.

Having said all that, I worked on updating a port these last days where the upstream build system is entirely focused on building such an "everything but the kitchen sink" package, even downloading and building dependencies automatically. It was a major PITA to convince this beast to *just* build the actual application. It seems devs got tooo used to these stupid bandaids. Not great...


----------



## cabriofahrer (Jul 16, 2022)

Zirias said:


> There's nothing wrong with wanting an application to run in some isolated environment, but you can easily achieve that yourself, putting it (and its dependencies) in a jail.


I am not so sure if that is the intention of people who would like to see snapd / flatpak implemented, but rather to be able to (easily) install certain programs that have not been ported to FreeBSD.
And I must say that your input on this is indeed very informative and explains another point why FreeBSD in some way is better than Linux...


----------



## Menelkir (Jul 16, 2022)

cabriofahrer said:


> install certain programs that have not been ported to FreeBSD


FreeBSD can't run linux binaries without a compatibility layer, which is not perfect, specially about those package manager that uses special linux features. Even so, why you need a second package manager that will be used to install an application that will only be used in one OS? Because the selling point of flatpak/snap is "make an application in whatever distribution and run in whatever distribution", while in FreeBSD you'll make a package that will only runs on FreeBSD (which is obviously in the ports). Unless we're talking about contraptions that can't be accepted on ports...


----------



## kpedersen (Jul 17, 2022)

Snap and flatpack should probably be supported by the Linux compat environment in the same way that msi, setup.exe and all that other crap is supported by the Windows (Wine) compat environment.

Your best bet is to just extract the Linux binaries out of all that cruft and run them in a Linux emulation chroot. These "technologies" do little more than that anyway minus all the weird loopback mounting and messy stuff like that.


----------



## Menelkir (Jul 18, 2022)

kpedersen said:


> Snap and flatpack should probably be supported by the Linux compat environment in the same way that msi, setup.exe and all that other crap is supported by the Windows (Wine) compat environment.
> 
> Your best bet is to just extract the Linux binaries out of all that cruft and run them in a Linux emulation chroot. These "technologies" do little more than that anyway minus all the weird loopback mounting and messy stuff like that.


The best shot would be appimage, appimage is pretty much a squashfs with everything inside, so less things to get bored to.


----------



## kpedersen (Jul 18, 2022)

Menelkir said:


> appimage, appimage is pretty much a squashfs with everything inside


Ah, appimage! I knew there was a third one. Yep, I *think* it is the simpler of them.


----------

