Getting Started on an Official Flatpak?

Contributing to Blender
1

I wrote a thread several months ago asking about the status of an official Blender flatpak that is now archived. The issue for this (#102949) has had zero movement for quite a while now; I find the situation frustrating, because it is the format distributions that aren’t Ubuntu seem to be adopting.

Snaps are essentially limited to the Ubuntu ecosystem; it’s poorly (or not at all) supported elsewhere. For example, Fedora (which has been getting more and more popular) does not support AppArmor, which means Snaps will not be properly sandboxed. AppArmor and SELinux in general are pretty much never supported together; Flatpak uses Bubblewrap instead, which is more agnostic as far as I can tell.

I believe an official Flatpak would be a big step in supporting a much wider range of distributions.

I saw in the discussion on the issue that one of the concerns is that directories are changed; this may, for example, mess with third-party installers that expect certain directories. I would consider that Flatpak users

  1. are probably unlikely to be using third-party installers
  2. may expect the directories to follow Flatpak conventions, rather than cluttering up their base system (this is especially true in the case of immutable distributions, where Flatpak/Snap usage is the norm).

Getting around to the main point of this thread, it was mentioned that other people could at least help contribute a packaging script; how could I get started on this? I have some experience programming, but little experience with contributing to open source projects.

8 Likes
3

The version on Flathub isn’t packaged by anyone from Blender, afaik, yes - and also Blender does not offer a Flatpak version in general. I feel that it’s going to be one of the more important packaging methods for Linux going forwards, so helping get some movement towards that started is what I’d like to try to do.

I did not check that (yet), but I figured it was better to ask about it here first - there might be Blender-specific requirements for a packaging script that I’m not aware of, and the people in charge of whatever relevant modules (is that the right word here?) might disagree with me on certain things, like the config directory for example.

Speaking of that, I know Windows Store apps are heavily sandboxed in a similar manner to Flatpaks; did the developers leave the config in the sandboxed directory there, too?

4

How is the download link for the Linux version on this page not sufficient, for a Linux user to download and use Blender?

5

If the point is being available on the platform in the first place, why are there four different ways a Windows user can download an officially provided version of Blender (portable, installer, Steam, Windows store)? How is the portable version not ‘sufficient’?

Under ‘Linux’ on the download button are two versions - Snap, which is poorly supported outside of Ubuntu, and the tarball, which may not be appropriate depending on your distribution (and, I might add, does not provide any update functionality). Immutable distributions in particular expect you to use packaging formats like Snap or Flatpak.

EDIT:
Additionally, offering Blender through channels similar to app stores avoids another problem; there have occasionally been websites masquerading as the official Blender website, offering malware pretending to be the actual software. As silly as you or I might find it, people do fall for this; it is helpful to offer reliable channels to download from.

Another thought is that Blender users often use scripts written by other people or open files uploaded by strangers; formats like Flatpak sandbox the app in a relatively user-friendly manner, minimizing the damage a malicious script might cause. There are numerous reasons someone (me included) may want a Flatpak version.

2 Likes
6

For the portable, I cannot answer as I’m honestly not familiar with why it exists. For Windows Store and Steam, I personally don’t feel those are necessary whatsoever. I download software from the website/source of whomever make it, not some "store’.

As to avoiding malicious downloads - I believe that’s on the user to deal with. The fact that nature provides both a safe walking space, and a cliff, doesn’t mean that nature should be required to ensure you don’t walk off the cliff… put down your phone, stop talking a selfie, and watch where you’re walking.

If Ubuntu or one of the other 10,000 distros out there does or does not support Snap, I think users should lobby (or rewrite it, as it’s FOSS) that distro to add support for it.

7

It is not so simple. Snap relies on AppArmor for sandboxing; many distributions opt to use SELinux instead. Snap has poor support for third-party repositories, leading many distributions to support Flatpak instead simply because it’s more open.

If anything, users of Linux lobby for Flatpak support over Snap support.
_
This isn’t nature. I fail to see the point of the comparison. Cliffs are not designed to trick you to walk off them. Not every Blender user is tech savvy. It is just one consideration among many.
_
If you don’t use Linux - as evidenced by the fact you download software from the website/source and not some ‘store’, as 99% of Linux software is obtained through repositories of various kinds - why exactly are you questioning this? How is this relevant to the topic of the thread, even?

2 Likes
8

If we offer Flatpak as an official installation method, I think users will overlap a lot with existing users and they would want add-ons and preferences to keep working.

I think third party installers are the least important issue with the paths though. Not sharing settings with other Blender installations is a bigger problem, also when migrating from an older to a newer version.

Perhaps a compromise could be to keep using the Flatpak config directory, but to offer importing existing settings from .config/blender, as we already do for previous Blender versions in the splash screen. And the Blender manual would need to be updated with information about where the config files are.

Unlike the current unofficial Flatpak package, we would want to create the Flatpak from the existing binary build as we do for Snap. So just repackaging that build rather than making a completely new one.

9

Though I think it’s a good compromise, I would consider that this means the flatpak either has to come with permissions to open that directory by default or access the config through a portal, which as far as I understand requires additional input from the user to select the file.

Granted, in order for the opening splash to work (mainly, the ‘recent files’ section) a Blender flatpak likely has to be shipped with a certain amount of open access in the first place. I am not completely familiar with portals, though, and don’t know if they allow dialogs like that to work. The ideal is of course to ship with as few permissions as is required. I suppose it would be helpful to look at what permissions the Snap asks for by default.

I recently discovered the developer documentation wiki, which should point me in the right direction to peek at how the Snap packaging works. It will take me some time to pick it apart, I’m reading quite a few things at once to wrap my head around all this.

1 Like
10

The Flatpak will have to come with enough permissions, just like the Snap package. Sandboxing Blender file access is not practical I think, if it’s suitable at all for this type of application that is supposed to integrate with other software and production pipelines.

11

I suppose that’s true; it would probably be best for permissions to closely mirror what the Snap package has, too, for consistency.

EDIT:
And the especially paranoid user could just modify the permissions themselves with Flatseal, if deemed necessary; then the cause of any file access issues would be immediately understandable.

12

Some notes after doing more reading, in case anyone else wants to get around to this (it may be quite a while before I feel ready to try).

The Snap manifest template specifies ‘classic’ confinement, aka full permissions. The Flatpak equivalent appears to be --filesystem=host and --share=network. The current unofficial manifest on Flathub also specifies these permissions, in addition to access to /run/spnav.sock - I have no idea why it specifies permission to that.

The unofficial manifest, as it is on Flathub, refers to a re-hosted Blender tarball (aka what is available currently through the download button, but on some mirror that I don’t believe is official, but I could be wrong about that) and an expected SHA256 hash for that link (which seems to match the SHA256 hashes provided via the download button, at least).

As I currently understand it, the Snap folder in the Blender repository is used as a template by Buildbot to automatically create a valid Snap manifest. A Flatpak manifest template would need to be written, in addition to a packaging script.

One question is, how would we prompt users to import existing settings? A bash script can be specified to launch Blender, which is how I assume the proper way of doing this would look.

I also just had the thought to wonder what happens if, say, existing settings are from another Flatpak package (i.e. someone is using an LTS release alongside a more current release; I think Flatpak supports release channels similarly to Snap. I do not know if Flathub allows this). Some more headaches if the normal directory isn’t used. Perhaps it’s just way simpler to find a way to use the default directory. Maybe this can also be solved otherwise, though.

How was all this approached for the Windows Store version, which I understand is an extremely sandboxed release format?

EDIT:
I also see the current unofficial package has a problem with the remapped /tmp directory filling up too quickly because of autosaves, causing problems with other Flatpak software.

Having --filesystem=host access does not include /tmp, according to the Flatpak documentation. A solution the unofficial maintainers suggested is using environment variables. Apparently the remapped Flatpak directory gets wiped clean when the application exits, so autosaves don’t work in the first place? Pardon the many edits, I got confused a few times trying to follow how this works.

2 Likes
13

I decided to spend more time today figuring out how this all works; where ARE the build scripts, particularly for the Snap package? I see the Snap manifest template, but am having trouble finding the actual build script. The developer documentation doesn’t seem to point me in the right direction.

And again, how was the problem of sandboxed directories approached for the Windows Store package?
EDIT: as per the user manual, the Windows Store version does not use the default config directory at all.

Just exposing permissions to the folder seems to be good enough to let Flatpak apps use their usual directories (do not quote me on this however), so this likely won’t end up being a concern, but at least one official release version already has this problem.

4 Likes
14

Now that we’re back, the new version is released, and it’s been 11 days, I am once again requesting some guidance (please). The documentation is only slightly enlightening regarding how the entire build process works. I don’t understand how - or where - the Snap manifest template is used in a build script, which is essential for writing a Flatpak manifest template.

Either the build script referred to in the folder containing the template is hosted somewhere else (another repository?), or I am blind. All I have to do to begin to understand is read it.

2 Likes
15

The automated build scripts are in a private repo that we still need to untangle to be able to share safely. But those scripts are not a good example of how it should be done.

An example you can look at this for example this one for pypi:

Basically we want a Python script that you would give a Blender release package for Linux, and that can turn it into a Flatpak. And eventually also a script that can upload to Flathub. There should be a README that explains how to use it, and which packages should be installed. This would run on Ubuntu Linux.

Then from there we can hook it up to our CI.

16

After doing some more reading of the various manifest files openly available on Flathub, official packages appear to, mostly, choose between one of two methods of turning apps into a Flatpak.

In each manifest is a section labeled ‘sources’, pointing either to a URL or local directory(?) (there may be a third method that I don’t quite understand yet). That URL can either point to a git commit or download link, which are the two methods I do understand. (My experience with git is very, very limited so far, so I only somewhat understand the first one).

In my eyes, the simplest method would be to have a script that generates a manifest pointing to a download of the latest version on an official mirror, then commits that to Flathub - or alternatively, it appears the Flathub package can potentially point to the manifest in Blender’s own git repository if desired.

Using official mirror downloads is currently what the unofficial Blender package does, but it has to be updated manually by the maintainers and ends up several days behind.

Would this be acceptable, or would doing it properly entail something different?

2 Likes
17

A little more research later and now I understand the process a little bit better - sorry for all the confused posts. My understanding, for anyone else interested; Flatpak manifests, as far as Flathub is concerned, are basically instructions for building the package. Pointing to a particular github commit essentially tells Flathub to build the package from source.

As per @brecht, I’ve gathered that it’s preferable to use a pre-compiled tarball. I asked because I wasn’t sure how long those fresh-built download links last, but if Flathub just uses the provided link to build and then provides the packages themselves from there, that answers the question - the Python script should build a manifest pointing to the latest stable build tarball just like the example.

It will be a while (I’m not sure how long) before I have access to a Linux machine and can try to submit a pull request for a basic start (I think I could manage a script/readme that just creates a valid manifest for the current version), so if anyone else out there has the time for it - don’t wait for me!

2 Likes
18

One question to resolve is, is it worth hosting our own flatpak package for download, or is everyone happy to download from Flathub and we just link to that from our download page, similar to snap?

Either way, it’s good to have our own org.blender.Blender.json and script that can generate the package, even if only for CI testing.

The upstream org.blender.Blender.json used to build from source but is now just using the binaries, which makes it very similar to what we would use ourselves.

There is some stuff regarding ffmpeg that I think we would leave out. We statically link ffmpeg into the binary, so I’m not sure that even accomplishes anything, as far as I know Blender will always use the static version. We plan to switch to dynamically linked ffmpeg for 4.1 which might help, but still unclear if there is enough ABI compatibility.

I imagine it would work like a template as we have for snap, where some strings get replaced by the version number to create the actual json for generating the package.

19

I just want to mention that i do use blender for (several) years ( since 2.4.? ) using the “un-edgy” debian distribution and even now sticking to debian 10 when 12 is already out… and never had a problem with the directly downloadable blender linux binaries… (even using multiples versions simultanously… )

So :+1: for this…

Only now with 4.0 it’s time to get proper openGL hardware… (a 4.0 alpha did worked :wink: )
20

I don’t see the advantage in hosting your own Flatpak package/repository. Using Flathub provides better integration with the app browsers (Discover/Gnome Software in the two big DEs) and a clearer mechanism for automatic updates. As far as I can tell, Linux users are generally happy to use Flathub where Flatpaks are concerned; especially if the app is verified.

I think the main question is how LTS/current release branches are differentiated, as it doesn’t appear that Flathub supports having more than one public release channel - it may end up looking like the mess that is the Windows Store release, with like 5 different versions of Blender available.

EDIT: Flathub does offer a ‘beta’ remote, but it is unwieldy to access for end users.

3 Likes
21

Hey all, I’m a long-time open desktop contributor, contributor to Flathub, and employee of the nonprofit Endless OS Foundation. At Endless OS Foundation we make a Linux-based OS (Endless OS) that heavily utilizes Flatpak for all apps, and includes Flathub as the source for apps out of the box. I also want to point out that SteamOS and Fedora Linux both include Flathub as the source for their built-in desktop app stores, now, too.

Personally I’ve always used Blender from Flathub, and I’d love to see it become more officially-maintained and verified; I can even help out with the process. :slight_smile: Snap is effectively an Ubuntu-only technology and while it’s not technically wholly proprietary, the back-end is, and only Ubuntu ships it and it’s only well-supported on Ubuntu due to the way Canonical has engineered it. It’s not realistic for any other Linux distribution to change how their entire security model works for Canonical’s app store, especially when the entire community has naturally come together around Flatpak and Flathub.

I would echo that Flathub makes the most sense as where to host a Flatpak; it’s the defacto app store for Linux distributions, even if Flatpak itself is a decentralized technology (anyone can host their own remote). But by shipping in Flathub, you get Blender in the built-in app store, out of the box, in a bunch of distros without the user having to go manually download a file or type a Terminal command.

The Flathub beta remote would be an ideal choice for automated builds and testing, but as @Coffee noted, it’s not the best for end users as it (intentionally) does not have a way to use it graphically. I would probably consider having a separate app listing for LTS versus current builds, but I’m not sure; a first step would be to get the current app listing officially verified, though.

All that said… what’s next, and how can I help?

3 Likes