Distributors entering Flatpakland [LWN.net]

Distributors entering Flatpakland

Posted Jul 8, 2022 18:20 UTC (Fri) by atnot (guest, #124910)
Parent article: Distributors entering Flatpakland

> a Flatpak package, instead, will list a single "runtime" containing the base set of libraries against which the package is built. If there are libraries or other dependencies that do not appear in the runtime of choice, they are simply bundled with the application in its flatpak.

This is not quite true. While applications will primarily depend on one runtime, runtime extensions allow some dependencies to be managed separately. For example, ffmpeg is available separately as the org.freedesktop.Platform.ffmpeg-full runtime extension. Similarly, the org.kde.Platform.Locale extension provides shared translations for KDE apps. Base apps also allow another form of dependency reuse, although those can not be upgraded independently.

to post comments

Distributors entering Flatpakland

Posted Jul 8, 2022 18:21 UTC (Fri) by jafd (subscriber, #129642) [Link] (9 responses)

So, this is like old packages but not quite like old packages? Can't it also use a normal packaging format internally?

Distributors entering Flatpakland

Posted Jul 8, 2022 18:35 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (5 responses)

> So, this is like old packages but not quite like old packages? Can't it also use a normal packaging format internally?

It's atypical but feasible and Fedora has it's own Flatpaks sourced from RPMs that is independent of Flathub. Refer to https://src.fedoraproject.org/projects/flatpaks/

Ostree, the underlying storage format used by Flatpak has support for OCI containers as well, refer to https://coreos.github.io/rpm-ostree/container/

Distributors entering Flatpakland

Posted Jul 9, 2022 9:03 UTC (Sat) by GvMariani (subscriber, #7320) [Link] (1 responses)

> https://src.fedoraproject.org/projects/flatpaks/
Broken link:
Page not found (404)
With the message:
Project not found

Distributors entering Flatpakland

Posted Jul 9, 2022 14:58 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

Looks copy/paste missed a char, here you go:

https://src.fedoraproject.org/projects/flatpaks/%2A

Distributors entering Flatpakland

Posted Jul 9, 2022 15:25 UTC (Sat) by jafd (subscriber, #129642) [Link] (2 responses)

Yeah, but what are the runtimes themselves made of? LFS? Some RPM/deb-based collection of software? How do I repackage runtimes?

Distributors entering Flatpakland

Posted Jul 9, 2022 16:32 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

> Yeah, but what are the runtimes themselves made of? LFS? Some RPM/deb-based collection of software? How do I repackage runtimes?

I would start here: https://gitlab.com/freedesktop-sdk/freedesktop-sdk

Distributors entering Flatpakland

Posted Jul 11, 2022 20:53 UTC (Mon) by bartoc (guest, #124262) [Link]

The runtimes themselves are some container image format, usually ostree, but fedora uses OCI in some cases. The packages do tend to come from the normal packaging ecosystem of whatever distro provides it. I think the freedesktop sdk might use yocto.

Distributors entering Flatpakland

Posted Jul 8, 2022 19:53 UTC (Fri) by atnot (guest, #124910) [Link] (2 responses)

It was already mentioned that this is possible, but I think there's a few differences and reasons:

1. Extensions are opt-in on an application basis. If an application does not need an extension, it is not there to cause trouble. Among other things, this allows you to both reproduce a user's system exactly and guarantee it will be the same as it is on your machine.

2. Multiple branches of an extension can be installed at the same time. For an example perhaps painfully familiar for a lot of us: if one has a python extension runtime, one could require branch 3.8 of it in one application, 3.9 in another and bundle a custom patched version in a third, without there being any ambiguity about what /bin/python refers to within each flatpak.

3. Because they are coarser-grained, the number of combinations that need to be tested are a lot lower. Most applications depend on at most one or two extensions.

4. Purely technically, use of tools like OSTree requires a very different format.

5. Purely politically, making a new package format designed to unite the Linux desktops and making it heavily rely on your own existing technologies is unlikely to go over well with other distros. (cf. Snap)

Distributors entering Flatpakland

Posted Jul 10, 2022 17:29 UTC (Sun) by gray_-_wolf (subscriber, #131074) [Link] (1 responses)

> bundle a custom patched version in a third

Could this lead to a fragmentation of an ecosystem for whatever interpreted language? As in, "I don't like this about python, so let me just patch that out". Since you will ship your own python anyway, you might not care. Am I too paranoid?

Distributors entering Flatpakland

Posted Jul 10, 2022 19:07 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

For Python specifically? Unlikely. All code lives in a single namespace with no way to make sub-namespaces (AFAIK). So if you want to patch `numpy`, you have to give it a new name and update all internal code to look itself up by that new name. Or you're patching *everyone's* `numpy`. The former is too much work for most people to bother with. The latter is bound to cause trouble with various mixes of packages and versions sooner or later.

If you're talking about the interpreter and its stdlib, who knows. Embedding Python into your own package is already a nightmare to do half decently. Attempts at "bring your own Python" packages have been a flop so far because you lose double-click on the binary. So we just ship our own and say "too bad" about anything else (`pip` is not shipped in a working condition because we disable OpenSSL; if we shipped that, we'd get hammered on every audit for being "out of date").