Flatpak builds are not reproducible and why that's a practical problem (2022) | Hacker News Reader

Flatpak builds are not reproducible and why that's a practical problem (2022)

ranfdev.com

34 pointsementally19 comments

That's not what bothers me.

My problem with Flatpak is how huge are the downloads, especially when on a metered connection.

Last month I installed Kdenlive, and the size of the downloaded files was around 3 gb, to which the app itself contributed around 40 mb. (I use Ubuntu.)

A week later, I wanted to install another app (I forgot which one), but again, it was 3 gb download for 30ish mb app.

And then this week I ran `Flatpak update`, and it needed yet another 3 gb to download just because there was a new Kdenlive version (again, around 40 mb)!

How on earth does it make sense to have to download 10 gb worth of data just for apps that only total 100 mb?

The goal of these things is not to write software that works but to write software that works4me. Flatpack, snap, docker they all exist to ship your computer to someone else.

I use Snap frequently, and yes, apps that would only take 10 mb as a .deb can balloon to 200 mb.

But I can live with that; it's a reasonable price to pay for separating apps update cycles from that of the OS.

I also use Docker. But even then, my Django app — complete with pytorch, numpy and several other "heavy" deps on top of python itself — is a little more than 400 mb.

Flatpak is on another level by itself!

Interesting bottleneck. Considering that flatpaks are basically small filesystems themselves, there's probably some redundancy to remove. I wonder if a simple de-duplication strategy at file level may be enough to fix that.

In Flatpak you define the dependencies as runtimes, and they are shared between apps. So for example when you install Kdenlive it will download the entire kde framework that is huge but when you install the next kde app it won't download it again

I genuinely can't understand how a 40 mb app can turn into a 3 gb monstrosity. I won't be able to do so even if I wanted to!

Easy: Like most other containers, it starts by bundling an entire general purpose distro. Though I grant it is surprising that the sizes are quite that bad; perhaps there were suboptimal choices made in an attempt to make the layers more reusable but it didn't work out?

Agree, I feel like there must be a better way to achieve what Flatpak does. I love it because it's the only major app platform on Linux that offers some form of sandboxing, but the download sizes get ridiculously large.

> it's the only major app platform on Linux that offers some form of sandboxing

What about Snap? I use it all the time on my Ubuntu machines and works perfectly fine. Even files sizes are waay more sane than Flatpack's.

There's always x11docker, which AFAICT is actually quite good about sandboxing/isolating the app from the system.

And then by default everything is downloaded to /root rather then into user space, clogging up the partition. Not ideal for a partition that you would not expect to hold 20+GB worth of programs.

I was genuinely shocked the first time I tried to use Flatpak and thought something was wrong.

(2022), and the article was not 100% correct even then.

What was and still is wrong with it?

Builds are reproduceable

It feels like the update at the top entirely invalidates the article. At least I don't see why pinning dependency versions at the source level would be necessary for reproducible builds.

On the one hand it has all the disadvantages of static linking, and on the other hand it has all the disadvantages of out-of-band package managers.

They are unfortunately a necessary evil for keeping LTS OS running.

Related: "Flathub is insecure for distributing cryptocurrency software".

https://github.com/feather-wallet/feather/issues/47

Guix seems the best when it comes to reproducibility https://guix.gnu.org/en/blog/2024/identifying-software/

Reply on news.ycombinator.com