Basically, if it's not code which I have written, I want to ensure that I am getting all of my packages managed through one central repository who I can trust to manage updates for me to ensure that there are no major breaks, or if there are, that a bulletin is issued in advance notifying me of what changed so that I can make any adjustments necessary before proceeding.
ZERO INSTALL APPS INSTALL
I've known about it for a few years, but I've never bothered with it because everything I need is in my distros repositories, plus I don't like the idea of many different versions available which haven't been tested with my particular configuration.Īnd besides, zero install is not something which I would want to use on my computer anyways, because I am not using my computer with a Windows mentality of wanting to have the latest and greatest of everything in order to have something break. Strictly speaking, packaging in one way or the other and shared libraries are separate problems but they are usually grouped as above.
ZERO INSTALL APPS UPDATE
On the "plus side", if an update would break your app you can keep the outdated insecure version. Another drawback is security: If each app includes specific versions of libraries, one security update turns into hundreds. However, in practice this does not work as cleanly as larger dependencies are probably split of again. The other approach is that all stuff belonging to application foo resides in a named subfolder which again is split as above. The "drawback" of this approach is that you do not immediately see what files belong to which application (though apt or synaptic can quickly show you). All binaries land in one folder, all documentation lands in another folder, all configs land in a third folder etc. The usual linux approach is nicely explained by the filesystem hierarchy (man hier). There people pointed out previous similar approaches like zero-install and klik or alternatives like nix.
You have probably seen the discussion about ubuntu's click packages.
0 kommentar(er)
