[edohyiez]

The main argument against this kind of bundling (apart from higher disk usage) is about security updates of libraries. E.g. if many applications ship their own copy of OpenSSL and another vulnerability is discovered, you have to update every application individually. And it is unlikely that all developers/vendors will provide such updates fast enough.

But if all applications use the same OpenSSL that is managed by dpkg+apt (or something similar), a single update will fix all applications.

Personally, I don't think that this problem can be solved without losing the advantages of bundling (robustness, reproducability, binary portability to other distributions).

[kayamon]

Right, but there's a difference between things that the OS is expected to provide (OpenSSL, GTK, etc) which the app should not bundle, and things like libpng which the app basically should bundle.

e.g. Windows supplies KERNEL/USER/GDI as builtins, but doesn't supply libpng.

Pretty much the whole point of an OS is to provide a guaranteed stable base. Anything that isn't guaranteed or stable should be bundled with the app.

[dbdr]

If libpng has a new vulnerability discovered, how do you make sure it is fixed in all the apps that bundle it?

http://www.cvedetails.com/vulnerability-list/vendor_id-7294/...

[edohyiez]

GTK indirectly depends on libpng, so that probably wasn't the best example ;)

The thing is that Linux distributions traditionally don't make any difference between the OS and apps. Everything is split into relatively small packages. Like everything this model has some advantages (e.g. security updates) but also some disadvantages (it's harder to distribute/install software outside the distribution).

[davexunit]

I would argue that you shouldn't bundle any libraries at all. As a package maintainer, I get real annoyed at projects that bundle things like libpng and don't provide an easy way to use an already built version.