Closed: Is the inability to install flatpaks from Ubuntu/Gnome Software only a temporary limitation?

Desktop
1

I don’t have any problem with the Software app being a snap and I believe both snaps and flatpaks are great technologies that alleviate the enormous waste of effort and loss of market share that pervade the traditional Linux distribution model. I also understand the reasons for Canonical to pursue the development of snap instead of adopting flatpak. That’s all fine.

But today I bumped into https://jatan.blog/2020/04/25/how-to-install-flatpak-apps-on-ubuntu-20-04-lts/ which I find NOT fine at all.

As I see it, the snap “vs” flatpak meme is just misguided, it has nothing to do with the problem of having 200 distros, or even 2 distros, since the app developer can choose between snap and flatpak without losing users, they are two alternative routes to reach the same destination.

But dropping support for flatpak from the official app store seems to me like an aggressive move. Is that just a temporary artifact of migrating Ubuntu/Gnome Software to snap or a strategic decision Canonical has made?

5 Likes
2

I think it is a usability mess to have multiple sources with overlapping packages in the same place.
I think myself as a power user and I could certainly handle such a situation.
However, I can also think of the majority of the users would do not want deal with such a mess.

You say aggresive move which makes me think that this thread is going to derail really badly.

3

I think it is a usability mess to have multiple sources

Given that you’re leaving out every app developer that decided to go flatpak instead of snap from the “easy-way point&click” software center, I find this reason not too compelling, more like bordering a pretext. Anyway, I’m not pretending that it’s the rationale behind this limitation but just answering to your suggestion.

You say aggresive move

I say it seems to me like an aggressive move and hence I’m frankly asking for clarification in the hope that I’m plainly wrong. I’m far from being impolite or denouncing anything, just asking.

2 Likes
4

there has never been support for flatpak in the official ubuntu-software application, you always had to manually install the plugin from universe, so nothing was dropped … you just install two packages today instead of one …

(note that there is technically no need to remove the snap-store, they can happily co-exist … though it is admittedly confusing to have them both)

2 Likes
5

Ok, so you’re saying that the “need” in:

Now we need to safely remove Ubuntu’s snap store to avoid redundancy of features and confusion from the icons being similar.

is misleading?

That might seem a merely technical detail, a nitpick, but there surely is a difference between having to replace the “official solution” and having to complement it. That you need to install two instead of just one package has indeed little relevance.

It would be a good idea to make the icons different, at least, though.

Thanks for the clarification!

2 Likes
6

Just one more question, the possibility of adding a flatpak plugin in the future was more or less ruled out or is there some probability of getting it?

2 Likes
7

A person expressed a preference on their own blog. You are asking whether that preference is misleading, which is again loaded. It is just a preference, their preference.

3 Likes
8

As others have explained, we didn’t “drop” support for flatpak, because it was never baked into Ubuntu in the first place.

Since Ubuntu first began, we’ve tried to include and support only one of anything in the base distro. One email client, one browser, one init system, one display stack. The more we support, the more security attack surface, more bug fixes, updates, and general complexity for us and confusion for the user. Other distros have been doing the “kitchen sink” thing of lobbing everything into a 6GB ISO and that’s fine, each to their own, but that’s not been our path.

One of the down-sides of having multiple supported releases of Ubuntu out there is that people use it, a lot of people use it. There’s millions of users of Ubuntu 14.04, 16.04 and 18.04. Along comes 20.04 and that’s a lot of machines out there running varying releases of Ubuntu. Like any developer, it makes sense to optimise your workflow to get updates to users as fast as possible. 14.04 (now out of support for desktop) shipped Ubuntu Software Center. In 16.04 and beyond, we shipped a branded version of GNOME Software.

So we ended up having to maintain GNOME Software in 16.04, 18.04, 19.10 and 20.04. This is further made complex by the integration with processes on the host - such as fwupd, which can make backporting new releases hard, time consuming or impossible.

Back in mid-2018, we made a confined snap of GNOME Software and published it in the Snap Store and called it “snap-store” and it only had the capability to install snaps, no firmware updates, and no debs (and no flatpaks) because it was “The Snap Store” - a graphical tool to install snaps. The side benefit of this, is that users of other distros could snap install snap-store and get a GUI for installing snaps. This is handy if their distro of choice has no GUI for doing that. The additional benefit is we can offer this newer version of a storefront to older versions of Ubuntu so they also have a newer graphical frontend to the store, which is based on a newer GNOME Software codebase.

Skip forward to last year, and we’re planning out what to do for 20.04. We now have a snap which we can update very regularly, to update all those supported releases, and new releases going forward. So we switch the 20.04 release to use the snap, because we know 20.04 will be a long lived release, used by many people, so it makes sense to have a smooth path for us to update the storefront should any new features come along. Along the way, we evaluated what else was needed in the graphical storefront app to bring into parity with the one we already shipped in 19.10.

The two main features missing from snap-store (the snap) were deb installs (from archive and local) and firmware updates. These are the features that 19.10 shipped with. Flatpak simply wasn’t on the roadmap because it’s not a default feature on the Ubuntu desktop. It wasn’t done out of spite or malice, it just isn’t a thing we ship, just like VLC isn’t and Chromium isn’t. Just like snap support isn’t shipped on some other distros, flatpak support isn’t shipped on Ubuntu.

If a user of 19.10 or below wanted to add flatpak support to their system, they would have to install a software package. That is the same case today. Now, it’s fair to say it’s not ideal that the outcome of that is they end up with two storefronts, I agree. But that’s where we are.

Now, the deb support in snap-store landed a little late in the cycle, so some people threw their hands up at beta time and said we were replacing deb support with snaps. Nope. It just landed a little later than we’d like. Also, there were bugs which meant around beta time it didn’t actually work on every machine - (It works here!" was heard over the airwaves a few times). That’s where we are today. We have a snap of a graphical storefront, which enables us to push updates to millions of machines, when we need to.

12 Likes
9

You are asking whether that preference is misleading

I wasn’t asking about anyone’s preference but just about the need to remove one of the packages, which is an objective matter, and it should be obvious that the question was mostly rethorical in order to highlight the statement in that post that had triggered my doubts. Could you please stop the sanctimony, I’m not here trolling, I’ve expressed a sincere concern about a distro I use and like and it has been already answered.

1 Like
10

Thanks for the detailed explanation @popey! I have both installed and was confused at 1st, but now understand and agree. Cheers, 20.04 is a very nice release in my opinion.

1 Like
11

The icons are different on my fresh install. I’m using the Adwaita theme.

Apr27-2020
Apr27-20201079×381 350 KB

12

To be clear on something which may confuse people. The snap-store snap baked into a 20.04 system comes from the latest/stable/ubuntu-20.04 “track” in the Snap Store. (tracks are a means to have multiple supported releases under one name). If you manually installed snap-store (the snap) from the Snap Store (the repo) (ugh, confusing), then you may see a different version. Here’s what I have installed:-

alan@mcp:~$ snap info snap-store | tail -n 8
tracking:     latest/stable/ubuntu-20.04
refresh-date: 4 days ago, at 04:03 BST
channels:
  latest/stable:    3.31.1+git187.84b64e0b 2020-04-22 (415) 45MB -
  latest/candidate: 3.31.1+git187.84b64e0b 2020-04-20 (415) 45MB -
  latest/beta:      3.36.0-75-g02a9109     2020-04-23 (436) 52MB -
  latest/edge:      20200414.ac9047f       2020-04-14 (375) 50MB -
installed:          3.36.0-74-ga164ec9                (433) 52MB -

So note I am “tracking” latest/stable/ubuntu-20.04 which contains 3.36, and the latest/stable (default if you don’t specify a track, and manually install yourself) has 3.31. I believe we plan to push an update to latest/stable this week so they’re in line. But we didn’t last week because that snap has many thousands of installs across 18.04 and many distros, and we didn’t want to cause more trouble for ourselves, what with 20.04 just being out the door. It’ll get updated shortly. Alternatively people can snap refresh snap-store --channel=latest/stable/ubuntu-20.04 to get the “default” one you get on 20.04.

5 Likes
13

Thanks @popey for the detailed explanation!

it just isn’t a thing we ship, just like VLC isn’t and Chromium isn’t

I find this comparison a bit forced. Ubuntu has an important share of the Linux desktop market and by making flatpak even slightly more difficult to use you might be pushing developers that are more or less indifferent about packaging technology towards snap, that way creating some level of network externalities that could reinforce the process. What I’m afraid here is that snap and flatpak end up being something like the new deb and rpm, though I gladly envision a future in which both coexist at the same level in every distro, that is enjoying comparable, if not equal, support. I don’t want to exaggerate my point, it’s not difficult to install a flatpak in Ubuntu, it’s just that we’re talking about technologies designed (among other things) to make installation point&click-level easy, and slight usability differences could lead to important imbalances when coupled with the aforementioned network effects. That’s why I’m not concerned about Chromium being a somewhat experimental snap, while Firefox has the (temporary) advantage of being a time-tested deb, but OTOH I’m concerned about different levels of support for what are arguably the two most popular “universal distribution channels” nowadays (obviously I don’t expect you to support rpm nor PKGBUILD, slightly less obvious I don’t expect you to support AppImage on par snap).

14

The comparison to VLC and Chromium was merely to illustrate that we make choices, and those typically mean we have one of each category or class of application or technology. We never set out to ship all technology baked into the distro. You’d be unsurprised to find we favour the technology we created or support over others, where that makes sense.

You could class package managers as a special snowflake which requires all being supported, others might suggest we should support every init system, or every LSM (Linux Security Module) because it makes sense for their needs. You can’t please everyone.

Flipping things around, you’ll note that a fair number of distros don’t support snap out of the box. As a result, we publish documentation which highlights how to install it on each of them, to reduce the friction for users. I understand flatpak do the same for distros which don’t ship it, or are outdated, so users can get the latest and greatest.

Also bear in mind Ubuntu is more than just a desktop OS and Snaps aren’t just for desktop applications. There’s a ton of non-desktop things (command line utilities, compilers, server applications and appliances) which exist in the snap store. A lot of people have a very myopic view that snap, flatpak and appimage (and whatever else they come up with) are only directly comparable on the desktop, and all other use cases do not apply. We don’t see it like that, so would prefer to ship a default set of technologies which service whatever packages are baked using the tools we prefer, and not have a mixed set of technololgies “Why don’t you just use snap for IoT and flatpak for desktop?” which makes even less sense.

6 Likes
15

Thanks again @popey, at the risk of being repetitive I’m going to highlight some points where I feel we’re not getting at common ground for reasonable disagreement.

others might suggest we should support every init system, or every LSM

Others might do that, but I just presented specific arguments for the case in point: enabling the flatpak plugin is a relatively simple operation (compared to, say, supporting systemd and sysv-init) and there might be some significant externalities in action that go against one important motivation for both snap and flatpak: to be universal. In a sense, it’s a more horizontal or cross-cutting concern than Chromium or VLC, each in their own vertical, and that’s why I found the comparison lacking.

Flipping things around, you’ll note that a fair number of distros don’t support snap out of the box.

I know, I wasn’t that happy either when Fedora “disabled” the snap plugin. As an insider you have a lot more perspective than me on the ultimate reasons for these decisions, but they may come as a potential threat for concerned users.

Also bear in mind Ubuntu is more than just a desktop OS and Snaps aren’t just for desktop applications.

I’m fully aware of this and I understand snaps are not replaceable with flatpaks nor AppImages, I’m far from suggesting something like that. TBH I even prefer snaps for the desktop above the other technologies, but I’m trying not to make any point based on personal preferences.

16

I haven’t been involved in every conversation about what gets enabled / disabled or included / excluded from being in the ISO / main part of the archive. I suspect there’s some decision somewhere which aligns more with the flatpak plugin which we haven’t included but I can’t summon one right now. Perhaps others can think of one, but I don’t think it necessary for this discussion.

However, I’m aware there’s certain requirements which need to be reached before something can be on the ISO. Not least of which is whether it’s part of the product strategy, which in case it wasn’t painfully aware from my previous comments, it isn’t. This should not be surprising news to anyone. Just as snaps aren’t part of the product strategy for other distros.

As with anything we don’t ship on the ISO, the outcome remains the same, you can add it post-install.

3 Likes
17

that can’t really happen because they are completely different things …

while deb and rpm are both package managers doing the exact same thing just in different ways, flatpak is a delivery mechanism for desktop applications and nothing more, while snap is a fully fledged package format …

you can install a ton of cli tools via snaps, servers, hell… even kernels and bootloaders … we even have a whole “snap only” distro called Ubuntu Core … none of this is possible with flatpak so IMHO compating them is rather moot, flatpak does one thing … and it does that well, but it simply isnt a general puprose package tool …

3 Likes
18

One other potential thing to be aware of is that the snap-store snap is currently strictly confined, and we in snapd added policy to allow the snap-store to manage debs. For it to manage flatpaks we would need to do the same. I don’t know the full set of security policy that would allow the snap to manage flatpaks over debs (perhaps packagekit-control already allows this but I seem to remember it doesn’t), but AFAIK that is another reason why the original snap-store snap only managed snaps was because we didn’t have the policy to allow it to manage debs, but we added/worked on that when it was requested. I.e. see https://github.com/snapcore/snapd/pull/7054 and https://github.com/snapcore/snapd/pull/7042.

4 Likes
19

Hello,

I’m a newbe but still I experienced somehow similar story that I want to share. Not about flatpack but about software suggestions in activities in gnome-shell. After migrating from 19.10 to 20.04 I was surprised that software was not suggested anymore. Like if I typed “irc” there was nothing… not Polari nothing. Same for “remote”: if I type “remote” vinagre along with remmina used to be suggested on 19.10 but nothing on 20.04.
Note that I use minimal install (both for 19.10 and 20.04)

After doing research I’ve found that I had to manually install gnome-software package. And that actually that this removal of gnome-software was mentioned in release notes. Bur being serious now, who on this planet reads release notes when installing desktops???

Long stroy short: if removing gnome-software wouldn’it be nice to include snap-store as a search for gnome activities? Today I don’t know why it’s not integrated by default.

My 5 cents. Sorry for offtopic but did not want to start a new thread for such a small thing.
Keep a nice job. I love my Ubuntu. Thank you for making it work.

Edit: Actually there is a bug filed

1 Like
20

The curious thing about flatpaks is that snap-store declares support for the associated mime-types, despite not supporting them. So you click on a pretty Install button on FlatHub, you get a .flatpakref file downloaded by your Firefox, you launch that, and you get snap-store saying that flatpaks are not supported.

I’ve filed a bug.

5 Likes