On Sun, Feb 09, 2020 at 11:12:48PM +0100, Manuel A. Fernandez Montecelo wrote:
2) These kind of methods are done for special packages like firmware, very popular apps like flash (at the time), etc, or *data* packages from games.
We have game-data-packager (gdp, which I originally wrote) for situations like this. When you generate a .deb (as gdb does) containing the data and install that, you get an Installed-Size which reflects the actual disk usage of the package; you know that data is removed again when you remove the package; you can express package inter-dependencies properly, etc. The ember package, at present • claims to have an Installed-Size of 35.8 kB but will install 177+MiB in pre-inst • Does not clean that up again on package removal • Doesn't handle "snap install" failing, silently completes package installation • Supplies a .desktop file referencing Exec=ember but does not provide any ember binary (even as a route into the snap) in $PATH It would be interesting to see whether game-data-packager could consume data from snaps, and avoid all these pitfalls. I believe smcv was interested in something similar for flatpaks (that might have been installing into flatpaks, rather than consuming from them) -- 👱🏻 Jonathan Dowland 🔗 https://jmtd.net