Chris's Wiki :: blog/sysadmin/ApplicationBundleProblems Commentshttps://utcc.utoronto.ca/~cks/space/blog/sysadmin/ApplicationBundleProblems?atomcommentsDWiki2014-08-11T14:34:21ZRecent comments in Chris's Wiki :: blog/sysadmin/ApplicationBundleProblems.By Josef "Jeff" Sipek on /blog/sysadmin/ApplicationBundleProblemstag:CSpace:blog/sysadmin/ApplicationBundleProblems:15454270e82321e8b632b22c6e3451956ae162afJosef "Jeff" Sipekhttp://blahg.josefsipek.net<div class="wikitext"><p>FWIW, the duplication you speak of reminds me of the arguments surrounding static vs. dynamic libraries (including libc!).</p>
</div>2014-08-11T14:34:21ZBy Ewen McNeill on /blog/sysadmin/ApplicationBundleProblemstag:CSpace:blog/sysadmin/ApplicationBundleProblems:c6b567914b992036978b3ff2cc87536a62235f48Ewen McNeill<div class="wikitext"><p>In addition in the case of (binary) "application bundles" (provided by third party OEMs) the "application bundle" may be the only sane way that they can ensure that a given instance has the versions of the libraries that they have tested (quality controlled) their application with. They may well be targeting a variety of base operating systems which have had a variety of (OS vendor) patches installed. So it's actually done to <em>reduce</em> support costs (by minimising the "dependent ABI" surface done to just "common across all OS versions supported" requirements). Much as I wish it weren't the case, for <em>third party</em> OEMs, with no ability to change or dictate the base OS, distributing <em>binary only</em> software, that needs to work seemlessly across <em>multiple base OS versions</em> it may well be the only sane choice. Especially since all of these platforms do not have a sane globally-installed third-party-usable method for installing packages and specifying their dependencies on particular versions of those other packages.</p>
<p>Anywhere else, like you it appears, I'd much rather see a minimally bundled application packaged combined with a set of machine-readable dependencies on other minimally bundled packages -- on down to the OS vendor base set. Such as is done in Debian, etc. <em>Because</em> it ensures that everything is built against a common set of base dependencies, which have been verified to work together. And it ensures that, eg, a security update only needs to be applied in a few obvious places. This is the "system integration" part of an OS distribution. Anything else feels more like a "Docker"/"container" approach, rather than an application package prepared by the OS distributor.</p>
<p>Ewen</p>
</div>2014-08-11T05:48:58Z