Getting Started on an Official Flatpak?

[Coffee]

@cassidyjames my understanding is that this is what needs to happen, in order:

1. Add a Python script that generates an appropriate Flatpak manifest (using a template similar to the Snap manifest) using the current build, and readme for using that script. It looks like it would need to take the git commit hash & version number as arguments to get the proper link to the build, like the example Brecht linked a few posts above.

Some decisions have to be made here regarding ffmpeg and certain permissions. There are open issues on the unofficial Flathub repository that mention some problems, like autosave files filling up directories with limited space. There appear to be additional issues with autosaves not saving correctly in general.

2. A script that can push the manifest to Flathub on release day.

3. The people more involved in the module have to hook the scripts up with the build system, and finally get the app verified by communicating with Flathub.

I’d try to help out if I had access to a Linux machine, but that’s not in the cards for quite a while. I’d be delighted to hear you picked it up.

[Domojestic]

It’s been a few months since this was last discussed, but I wanted to throw in one more voice that would be super happy to see a verified Blender Flatpak! The universality and ease of download is something that I think a lot of newer Linux users could benefit from, especially since some Ubuntu derivatives go as far as disabling snaps, making it harder for users using “beginner-friendly” distros to get their hands on the more hassle-free version of blender (considering the alternative is a tarball).

[ChrisHRD]

To echo the sentiment of many of the posts here, an official verified flatpak of Blender on Flathub should be considered a valid development concern for the future. With the steady rise in popularity of immutable distributions like Fedora Silverblue/Kinoite/Atomic-Desktop and SteamOS, trusted flatpaks are slowly becoming more expected than supplemental.

My small anecdote would come from the three 3D modeler that I sysadmin for. After years of using Blender across Arch/Debian/Manjaro/Ubuntu, they adopted Fedora Kinoite + Flathub. They expressed a noticeable difference in their work life. Rollbacks removed update fears, OS and apps lived in their own bubbles, and they could just simply focus on their work. On my end it was nice to have SELinux, modern kernel drivers, the flexibility of the Plasma desktop, and a 1-year support window to work with. However, I have genuine concern over the unofficial nature of the Blender flatpak. Malicious imposter apps are appearing on other application store fronts and 3rd-party maintainer fatigue is real. Not guaranteed to happen in this particular instance, but still could.

My hope is that the project might one day see the value in officially distributing via Flathub (or possibly their own flatpak repo). Not to excited about the thought of going back to mutable Linux distros and their versions of Blender.

[okidoki]

I wonder what the problems are to simply extract the official packages and then just run them… also multiple versions… ( as said above: using several on older system and even back to 2.49…)

( It just seems to be a “solution” for something which might just be no problem…)

I’m curious and would like to hear about the problems when just using the official packages…

[Coffee]

To re-iterate what has already been said several times, it is a security issue. Downloading packages from websites has inherent risks. Blender’s website could be hijacked or an imposter website could be created (this has happened before). Both cases lead to malicious packages being provided. A watchful eye helps prevent this kind of thing, sure, but not every Blender user is spending time making sure it’s the right URL, the download’s SHA256 hash is the same, etcetera.

Furthermore, automatic updates aren’t provided. This might not seem like an issue for a single user on a single computer, since in that case it’s just a convenience (a really nice convenience, I might add). But for someone managing a fleet of several computers (examples: education, a studio), using systems like Flathub or other package managers makes it a lot less of a headache to send a single update command to several systems at once.

Thirdly, it is an uncommon workflow to download packages directly when working with Linux systems. The proper solution is nearly always to go to your distribution’s repository or a system like Flathub. ‘Just download from the website’ is a very Windows-centric viewpoint.

When it comes to Linux, people normally just download Blender from a repository, but that is becoming less common with the advent of immutable distributions like Silverblue or Steam OS (yes, people do use Blender on the Steam Deck!), which typically rely on Flathub to provide software. Layering packages on top of the OS is discouraged on these distributions, particularly since it can make updating SIGNIFICANTLY slower and buggier.

If that still somehow doesn’t make it clear, I am uncertain what you’re confused about.

[okidoki]

But an official flatpak could not be hijacked ??
And the automatic update does also have no negative implications at all… ?
(Like: Some of my addons no not working in 4.xy… and everthign is different now… )

I think the possibility to use exactly that blender version you need for a specific project and having also all this installed in parallel is one of the advantages of blender. Updated sometimes changes some behaviour even slightly and so in a team this may cause trouble (if not using the LTS versions).

Also this is imposing the administration work for any IT to the “officials” from blender… so that they have to test another / that special environment…

Additionally:
If the official packages just work ( as mentioned ) the distributions could just re-pack (automatically after a new release on blender.org) their package when just using any /usr/bin/ path and the usual menu and file associations and it would just work… taking away the possiibility from the user to choose…

But wasn’t this individual packageing of the distributions the original reason why something like ImageApp, Snap or Flatpak was introduced in the first place ??

Again:
Because of the just work example blender may be just another alternative to those… which also has to be installed somehow, sometimes adding additional repositories (with possible misstyping and so prone to abuse ??)… so in some aspects similar:
→ download, extract (maybe over previous minor version), run…

So:
I see no need to make more work for the devs / building process. On the other hand people like @cassidyjames ( ) just offer their help instead of repraiseing some “believes” about the necessity of any additional package amount of work /effort

[Coffee]

There is no such thing as ‘cannot be hijacked’. An officially verified Flatpak would be signficantly more difficult to hijack, and certainly a more reliable source than a webpage.

Flatpak updates are automatable. They do not have to be automatic. You can simply leave it at the version you prefer to work with. Or just not use the Flatpak. Yes - you don’t have to use a Flatpak or a Snap if that doesn’t fit your needs! As it turns out, though, a Flatpak would fit the needs of other users. @ChrisHRD has already spoken about their needs as a sysadmin, and has stated a Flatpak would suit them.

Nothing about Flatpak itself prevents having multiple versions installed in parallel. You would have to ask Flathub about this. What works for your environment & needs is up to you to figure out.

How distributions provide their versions of Blender has nothing to do with this? Most that I’m aware of build their own versions from source anyway.

AppImages are inherently broken and rely on insecure, outdated packages to continue working. Snap and Flatpak were introduced to help solve packaging problems, yes, among other things like increased security (see the options for sandboxing).

I have no idea what your second-to-last paragraph is arguing. Any distribution that comes with Flatpak has Flathub already added as a repository by default. The crux of the matter is whether the package Flathub offers is officially packaged or done by a random third party.

The work added to the building process is minimal. If anything, it would more-or-less like how they build the Snap package that already exists as part of Blender’s official build process. That is, automatically. The bulk of the work needed is figuring out the permissions needed for the program to operate acceptably. Part of the issue is that Snap has a permissions mode that is essentially unconfined - Flatpak has no equivalent, as even the most permissive mode still has restrictions that need to have additional settings specifically lined out in the manifest.

As I’ve said multiple times in this thread by now, I would help by providing a Flatpak manifest template + Python build script for the package if I had access to a Linux machine (otherwise, as it is, I cannot test anything I write, which is a hard no for contributing). I am offering my help as soon as I do.

More succinctly, this thread was created to figure out what needs to be done in the first place. I don’t see why you’re arguing, as it’s not the point of this thread and several other users have stated interest in seeing this happen (for various reasons you can read about in said thread) or contributing directly.

[okidoki]

I just said:

It’s more work. For doing it and also maintaining it.

And… if linux distributions do their own packaging and so there is a need for a universal pack as for example flatpak… then the blender foundation already made a good job because their package just works.

And now you also tell that some paralled installation via flatpak is possible… and use the complex administraton arguement… so when an admin can;t do omethign like using some directory and symlinks like so:

/usr/local/bin/blender2.9/
/usr/local/bin/blender3.6/
/usr/local/bin/blender4.0/
/usr/local/bin/blender29 ->  /usr/local/bin/blender2.9/blender
/usr/local/bin/blender36 ->  /usr/local/bin/blender3.6/blender
/usr/local/bin/blender4 ->  /usr/local/bin/blender4.0/blender

and use some scripts to download and verify (md5) this for the versions and extract on the according directory…

It’s just an opinon like yours…

If the BF is happy do provide this if someone does the work (as it seems there ares some) … fine.

As mentioned…

@brecht

but still unclear if there is enough ABI compatibility.

…so… additional tests - > work → time to be used not for bugs or further developement…