Distributors entering Flatpakland [LWN.net]

Distributors entering Flatpakland

Posted Jul 8, 2022 19:53 UTC (Fri) by atnot (guest, #124910)
In reply to: Distributors entering Flatpakland by jafd
Parent article: Distributors entering Flatpakland

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)

to post comments

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").