I noticed that flatpak was using a lot of storage space (11 GB in /var/lib/flatpak). So I ran flatpak list --columns=ref,size to see what packages were using the most space. I got the following:
The installed sizes of all the packages add up to about 3.7 GB…way less than the 11 GB total used by flatpak. I’d expect there to be some overhead, but it appears flatpak is using almost 3 times as much space as the total of all the installed packages! Does this indicate a bug in flatpak? Is it possible that there are temporary files generated by flatpak that should have been deleted but weren’t?
This is expected. Apart from a few common runtimes, these flatpaks bundle all their dependencies—so even if two flatpaks use library A, they’ll each carry a copy of it (unless it’s included in the few available runtimes). I’m quite sure this is the case for Flatpaks from Flathub but I haven’t checked to see how Flatpaks from the Fedora repositories are generated (they’re generated from our rpms but I don’t know the pipeline well enough)
This is different to how software that is installed using rpm/dnf works—there, as far as possible, we only have only one copy of each dependency as a system level package that is used by all other packages.
You can try app images and snaps snaps are smaller than flatpak but it take slightly more time to open in my device but in ssd it is not a issue. Else rpm i always there if you want the smallest package.
That explains why flatpaks use more space than rpms… but I would expect the space used by those bundled dependencies to be reflected in the installed size of the flatpaks. Why isn’t it?
Hello @jhaiduce ,
Flatpaks are containerized apps, and indeed they do bundle a lot of their dependencies, and if the flatpak maintainer isn’t caring there will invariably be more than you would expect. However the internals of Flatpak are explained very well at https://docs.flatpak.org/en/latest/under-the-hood.html. If you read through their doc’s you will see how they work and how the runtimes are used etc… I think if you do a bit of digging into this you will find that there is not as much bloat as suspected and that the missing storage you cannot account for becomes accounted for.
Thanks @jakfrost, I see in the page you linked that flatpak uses hard links to version files, which could result in some files being double-counted by tools like du and baobab. I’m not sure how to verify that this actually accounts for the extra space though.
Yes they do bundle there dependency with there apps and run in a container same as flatpak but with there packaging way the ultimate app is smaller than the flatpak now i have downloaded them from both for various apps and come to the conclusion… that snaps are smaller in size than flatpak.!
ex:
That seems peculiar. I think that’s supposed to be just metadata? (It’s what’s shown in GNOME Software.) What’s the disk usage for subdirs within that?
No idea what happened but something is really wrong with /var/lib/flatpak/appstream. If it was my system I would delete (rm -rf) that directory. Appstream is going to be rebuilt by Gnome Software.
Will my flatpak apps still work in the meantime (i.e., after I delete the contents of /var/lib/flatpak/appstream but before Gnome Software rebuilds it)?
Is there a way to rebuild the appstream directory from the command line instead of waiting for Gnome Software to do it?
Thanks @mattdm and @augenauf, I renamed appstream to appstream.old just to be safe in case something goes wrong. Flatpak apps run without error. But I get errors trying to update the appstream folder:
$ flatpak update --appstream
Updating appstream data for remote fedora
Updating appstream data for remote flathub
Error updating: Error deploying appstream: Opening content object d232a00e9b8f42e532d6505ae230413a53c9d2bdde7466f4bf46355dd3d496e1: fgetxattr(user.ostreemeta): No data available
