Apps that have flatpaks

#1

Was just curious what default deb apps might be ready to go flatpak.
From a security/confinement point of view Evince or eog/shotwell seem like good targets. Of course gnome-fonts or gnome-calculator might be really easy to switch to.

Evolution or Brasero might not be worth installing by default depending on how much they are actually used (of course with Brasero that doesn’t give a good way to get that functionality…).

Flatpak exists (and maybe ready):

eog - can’t view items in trash
evince - can’t view items in trash
evolution
gedit - not all plugins may work
gnome-calculator
gnome-clocks
gnome-contacts
gnome-font-viewer
shotwell

Flatpak exists with apparent blocker

file-roller - possible issue #4
baobab - can’t delete things
gnome-logs, out of date flatpak exists

No flatpak exist

brasero
gnome-system-monitor
gnome-terminal
simple-scan
nautilus

3 Likes
Dreams of a flawless Brasero remain dreams
#2

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.

#3
#4

Thanks for your research here!

I agree that Evince, EOG and Shotwell are good targets. At least for Shotwell there would need to be a data migration step, and we just didn’t have the resources to work on that. (For Rhythmbox we just accepted that the switch to a Flatpak will lose playlists; it would be great to fix that but again, time.)

There is some prior art for migrating non-Flatpak config & data to the right location for a Flatpak, namely chromium. Maybe a simpler version of this could be used for Rhythmbox, and other stateful apps like Shotwell. Most of these apps probably don’t have significant state that would need preserving.

Evolution – of course there is a big data migration piece here, but one aspect that gives me pause is the interaction with evolution-data-server on the host system. We need eds on the host for gnome-shell, and I believe some Flatpaks like Calendar, Todo, and Contacts (from that list :)) use it, but Evolution’s Flatpak bundles another complete copy of EDS. So then, does this mean everything will be fetched twice? Will the shell show different calendar information to the Evolution Flatpak?

As you may be aware, we migrate apps from the OS to Flatpaks in the following way:

  1. Remove the app from eos-meta
  2. Tell eos-updater to automatically install it on an upgrade via a file in https://github.com/endlessm/eos-application-tools/tree/master/data
  3. Update eos-image-builder to install it by default
  4. Data migration through ad-hoc scripts in eos-boot-helper, or not at all
#5

On a related note, I kind of feel like we lack an adequate mechanism to describe something which we’d ideally like to be installed across an upgrade, but don’t otherwise want to make mandatory on new systems.

For instance I wouldn’t necessarily bother installing Evolution on new images (particularly base images) but if we’re upgrading, just disappearing it unceremoniously is unkind - ideally we could key off evidence that it was being used, but I appreciate that’s pretty hard to check elegantly at a system-wide level, or at the very least only install the Flatpak when upgrading from an older system that had it bundled.

At present the image builder will fail a build if any of the auto-installed Flatpaks are not installed already, which prevents the upgrade and new image apps from differing.

Do we need a way to say an installation operation is for upgrades only? Or just that failures are acceptable and the image builder can take that to mean, it’s OK if this auto-installed flatpak turns out not to be there.

#6

We have one, kind of. /var/lib/eos-application-tools/flatpak-autoinstall.progress stores the progress separately for each file. e.g. here’s mine on master:

[50-default.json]
Progress=2021020500

[51-rhythmbox.json]
Progress=2021022200

[52-cheese.json]
Progress=2021022500

So we put apps of this nature into their own file, and then have the image builder put the right timestamp into this file to squash the check. Kind of a hack but we have used it to omit, err, Hack at least once.

I can’t remember the details but I have a vague memory that we added this check in the image builder precisely because we forgot to add some essential app on new systems…

#7

Thanks! I definitely didn’t know about eos-application-tools. That’s key.

Submitted PRs for evince and eog.

Going to look into how Silverblue handles evolution and other apps. May take a stab at shotwell migration too.

1 Like
#8

Refocused on shotwell with migration- https://github.com/endlessm/eos-boot-helper/pull/356

May also look later at this evince possibility - https://github.com/flatpak/xdg-desktop-portal-gtk/issues/357

#9

Added the other bits for shotwell: eos-meta eos-application-tools eos-image-builder