Flatpak package for Linux releases #102949

New Issue

Brecht Van Lommel · 2022-12-05T14:15:59+01:00

Brecht Van Lommel commented

2022-12-05 14:15:59 +01:00

Blender on Linux is already available as a Snap package. Flatpak seems to be the more popular format at least on non-Ubuntu based distributions, so it would sense to officially support it as well.

There is no concrete timeline for this, but has come up a few times among developers, so good to have a task.

Flatpak sets different XDG variables for config and other files. Consider using same directories as other Blender installs instead. But can we access the unmodified XDG variable somehow?
Packaging script in Blender repository
Take over maintenance of existing Flathub package?
Buildbot integration
- Package
- Upload to download.blender.org?
- Release to Flathub

Blender on Linux is already available as a Snap package. Flatpak seems to be the more popular format at least on non-Ubuntu based distributions, so it would sense to officially support it as well. There is no concrete timeline for this, but has come up a few times among developers, so good to have a task. - [ ] Flatpak sets different XDG variables for config and other files. Consider using same directories as other Blender installs instead. But can we access the unmodified XDG variable somehow? - [ ] Packaging script in Blender repository - [ ] Take over maintenance of existing Flathub package? - [ ] Buildbot integration - [ ] Package - [ ] Upload to download.blender.org? - [ ] Release to Flathub

👀 1

Brecht Van Lommel changed title from ~~Official flatpak package for Linux releases~~ to Flatpak package for Linux releases

2022-12-05 14:29:31 +01:00

Pinus commented

2022-12-05 22:21:47 +01:00

Flatpak containers are somewhat more popular than Snap packages, but just as undesirable,
because both container systems slow down the system and become extremely bloated over time.

I would suggest using the Appimage format instead of Flatpak or Snap containers.
This would also have the advantage that everything that is needed can always be packed into the
Appimage, and this Appimages can also be updated without any problems.

Appimages also run on all Linux systems (!)

Flatpak containers are somewhat more popular than Snap packages, but just as undesirable, because both container systems slow down the system and become extremely bloated over time. I would suggest using the Appimage format instead of Flatpak or Snap containers. This would also have the advantage that everything that is needed can always be packed into the Appimage, and this Appimages can also be updated without any problems. Appimages also run on all Linux systems (!)

👎 1

Brecht Van Lommel commented

2022-12-06 01:49:46 +01:00

Do appimages do much beyond the Linux release package we already provide? We have a self contained package that can be run on many Linux distributions.

My understanding is that unlike snap/flatpak, it's not really meant for app stores or automatic system integration into launchers, menus, command line.

Do appimages do much beyond the Linux release package we already provide? We have a self contained package that can be run on many Linux distributions. My understanding is that unlike snap/flatpak, it's not really meant for app stores or automatic system integration into launchers, menus, command line.

Pinus commented

2022-12-06 15:24:54 +01:00

The question is why snap or flatpak containers at all?
Both container systems offer no advantage over the existing zip/tar archive. This is then only a format that must be
maintained and updated.

Distributions like Linux Mint refuse the integration into the system because of the proprietary character of Snap Container,
because only Canonical determines what comes into the Snapstore and what not. Faltpak is more open, because everyone
can provide a Flatpak.

The only advantage of Snap and Flatpak could be the possibility that one can install several versions side by side,
however one buys this advantage with enormous memory consumption and complex maintenance of the components.
in addition, the disadvantage that both Snap and Flatpak have problems with access to system folders, so where is the
advantage of Snap or Flatpak?

Appimages are less complex to maintain, and can be updated automatically using appimage-update. The advantage of
Appimages is that you can put different variants of help files or dlls in the Appimage, and that everything you need to run the program is included; this makes Appimages distribution independent.

With Appimaged (Systemd) and Appimage-Kit you can integrate it in the same way as Flatpak, but without the need for an additional runtime environment or root privileges.

But why use Snap, Flatpak, or Appimage Container at all?

The question is why snap or flatpak containers at all? Both container systems offer no advantage over the existing zip/tar archive. This is then only a format that must be maintained and updated. Distributions like Linux Mint refuse the integration into the system because of the proprietary character of Snap Container, because only Canonical determines what comes into the Snapstore and what not. Faltpak is more open, because everyone can provide a Flatpak. The only advantage of Snap and Flatpak could be the possibility that one can install several versions side by side, however one buys this advantage with enormous memory consumption and complex maintenance of the components. in addition, the disadvantage that both Snap and Flatpak have problems with access to system folders, so where is the advantage of Snap or Flatpak? Appimages are less complex to maintain, and can be updated automatically using appimage-update. The advantage of Appimages is that you can put different variants of help files or dlls in the Appimage, and that everything you need to run the program is included; this makes Appimages distribution independent. With Appimaged (Systemd) and Appimage-Kit you can integrate it in the same way as Flatpak, but without the need for an additional runtime environment or root privileges. But why use Snap, Flatpak, or Appimage Container at all?

Brecht Van Lommel commented

2022-12-07 12:57:20 +01:00

I don't really want to discuss the merits of Snap and Flatpak in general, that's been done enough in many other places. There are users/developers that like and use them, and others that don't.

The appimage update mechanism looks interesting, but seems like it would requite some additional work for us to serve those updates. I'm not sure we want to set up and maintain infrastructure like that for one platform / package combination.

I don't really want to discuss the merits of Snap and Flatpak in general, that's been done enough in many other places. There are users/developers that like and use them, and others that don't. The appimage update mechanism looks interesting, but seems like it would requite some additional work for us to serve those updates. I'm not sure we want to set up and maintain infrastructure like that for one platform / package combination.

Bartłomiej Piotrowski commented

2022-12-07 15:01:15 +01:00

Hey folks, Bart from Flathub team here. I'm happy to answer to any questions and also help integrate Blender's CI with Flathub publishing system, similarly to what OBS and Firefox do. Blender on Flathub is already re-using your binary artifacts since some time, so it would make total sense to skip the middleman that is the additional GitHub repo with the manifest.

Flatpak sets different XDG variables for config and other files. Consider using same directories as other Blender installs instead.

As the upstream, it's ultimately your decision, but I'd suggest sticking to the convention Flatpak uses. This way, if you decide to also publish LTS branch under a separate ID, it will use different configuration files than the regular Blender release, and would also allow users to launch Blender and Blender LTS simultaneously.

Hey folks, Bart from Flathub team here. I'm happy to answer to any questions and also help integrate Blender's CI with Flathub publishing system, similarly to what OBS and Firefox do. Blender on Flathub is already re-using your binary artifacts since some time, so it would make total sense to skip the middleman that is the additional GitHub repo with the manifest. > Flatpak sets different XDG variables for config and other files. Consider using same directories as other Blender installs instead. As the upstream, it's ultimately your decision, but I'd suggest sticking to the convention Flatpak uses. This way, if you decide to also publish LTS branch under a separate ID, it will use different configuration files than the regular Blender release, and would also allow users to launch Blender and Blender LTS simultaneously.

❤️ 2 🚀 1

Brecht Van Lommel commented

2022-12-07 16:14:53 +01:00

Thanks @barthalion. To be clear it might be a while until we actually start working on this.

Blender already uses different config files for different versions, to support running multiple Blender versions, so that's not really a problem. What happens is that users can install Blender in multiple ways, or download a daily build from blender.org, or even have 3rd party installers that make assumptions about where for Blender add-ons should be installed.

Thanks @barthalion. To be clear it might be a while until we actually start working on this. Blender already uses different config files for different versions, to support running multiple Blender versions, so that's not really a problem. What happens is that users can install Blender in multiple ways, or download a daily build from blender.org, or even have 3rd party installers that make assumptions about where for Blender add-ons should be installed.

Bartłomiej Piotrowski commented

2022-12-08 10:39:39 +01:00

To be clear it might be a while until we actually start working on this.

That's fine, just making myself available here if any questions pop in.

Blender already uses different config files for different versions

That's fair; ultimately, we're a platform provider, not packaging police.

> To be clear it might be a while until we actually start working on this. That's fine, just making myself available here if any questions pop in. > Blender already uses different config files for different versions That's fair; ultimately, we're a platform provider, not packaging police.

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Flatpak package for Linux releases #102949