PC-BSD 团队面临的最终导致他们废弃 PBI 并返回端口的详细的具体技术/组织原因是什么？
是因为编译和打包困难吗？是因为他们创建的硬链接有问题吗？还是因为收集依赖项并一起编译的工作量很大？
我很好奇为什么创建软件的同一个团队（比如GNUCash）花时间和精力为 Windows 提供一个独立的版本，而 *NIX 留给编译器/安装程序。
我不是在问为什么端口和库是好的（简单的安全升级，...）。我也不是询问软件包与 Windows 的偏好或意见，只是导致废弃 PBI 的技术原因。我特别问为什么PBI（0install，NixOS）的路线在技术上不可行或被广泛采用。
回到我使用 Windows 的时代，应用程序是以独立的方式安装的。这为最终用户/系统管理员提供了很大的自由来决定升级什么和在哪里，什么时候打补丁，而不会干扰其他应用程序。
在 *NIX 中，纠缠的依赖是一个令人头疼的问题。PC-BSD 试图通过PBI克服这个问题，通过创建独立的应用程序。AFAIK，这现在似乎已被弃用，他们回到了包管理方式（PBI 现在是端口的包装器），并且所有 Linux 发行版都朝着同一个方向运行：到最后有数百个依赖项，甚至桌面环境也有望依赖关于系统管理守护进程。
基于数百个依赖项构建应用程序使程序员的生活更轻松，但给最终用户和系统管理员带来了令人震惊的问题。例如，我不能再让一个古老的 Debian Etch 版本的应用程序在 Debian Jessie 中运行。我知道很多人都会谈到安全、补丁和最新系统的故事，但开源意味着可以自由决定更新什么、何时何地更新。有非常正当的理由不更新系统或其中的一部分，或者至少不按照典型的 *NIX 包管理器引导用户的方式进行更新（即离线工作的机器、旧硬件、与需要更新的旧数据的兼容性）保持合规性，...）。其他时候，系统管理员更喜欢分几个步骤来确保安全。
就个人而言，我认为我作为系统管理员应该决定更新什么，何时更新，并承担风险。以目前的情况，这是不可能的。（即在 Debian 中有一个新版本的 libc6，这在任何地方都有依赖关系）。如果我决定保留两个或更多存储库来解决这个问题，我就会产生另一个噩梦。
我知道某些依赖项（即安装了 MySQL）是可以接受的，因为这是一个主要的依赖项，但我不明白为什么像库这样的小依赖项不简单地嵌入到代码中。磁盘便宜。许多移植到 Windows 的 Linux 应用程序都实现了这一点。
编辑：以确保它不仅仅是基于意见
在 *NIX 中安装软件的选项有哪些（为了简单起见，我们将其称为 Debian/FreeBSD）以便：
保持软件的某个特定版本运行多年而无需升级，并确保无论后续的基本操作系统和库升级如何，都可以保持不变，ala apt-get hold但永远。
决定在不与其他软件/库冲突的情况下升级/降级。
安装该软件的两个或更多版本。
Jails/chroot/VM 不是选项，尽管它们是明显的解决方法。还，
distribution-choice package-management unix-philosophy distributions