Measuring dependencies size should probably be done differently
Opened this issue · 2 comments
I think using linuxdeploy —appdir=/executable/bundle -e /executable/app would probably be more accurate. Running linuxdeploy would create a bundle with a directory structure where it copies all the required dependencies into bundle/usr/lib. Of course linuxdeploy can then generate an AppImage but that step would probably not be needed.
Hmm, that's a good point, but I think it's up to debate whether it's objectively better. Yes, some dependency packages will have files that are not needed, thus inflating the dependencies size, however, in the case where someone is installing an application from their package manager, they don't really have the option to cherry pick individual dependency files.
On the otherhand, if someone wants to use the benchmark to determine which toolkit to use in order to create an AppImage, Flatpak, or Snap package, the method you mentioned would be more appropriate.
I'm not sure what the correct answer is here, maybe we can have a column for both? I'll leave it to the community to decide which they method they prefer.
This leads me to another question of "why stop there?". We could push this to its extremes and have every application statically compiled and linked with its toolkit, followed by LTO, PGO and BOLT. This is mostly just a thought experiment since it would be completely useless and impractical data, but it would be cool to see the results.
You’re right. Looking at what a minimal linux image for deploying an executable is more practical. Also it appears linuxdeploy sometimes misses some libs and has some other issues.