当权力没有挤出中产阶级并且有时间浪费“愚弄”等时，我曾经从头开始编译.tgz并手动获取依赖关系并安装到localdir
可悲的是，现在已经没有时间进行这样的l（in）uxuries所以我需要一种快速的懒惰方式来保持我的16GB Linux Boot OS分区尽可能小，并且有一个应用程序/软件/开发环境和其他数据单独的分区。
我可以处理将我的主目录安装到其他分区，但我的剩余问题是/ var和/ usr等以及每次安装时都安装的所有内容 - 我最终安装了一万亿个依赖项因为一个5kb的应用程序的作者决定不包括一个3kb的解析器，并希望我安装另一个50MB的包来获得那个3kb的库:)但是！
当然，当我卸载这些软件包之后，所有那些已经安装但从未真正需要的依赖项都会被遗忘。 但无论如何，重点是我不想手动编译并花费数小时追逐依赖关系，因此我可以编译并安装到我自己的路径，然后不得不修补一堆配置文件。经过一些研究，这是我能想到的最好的，我是否想念一些更简单的解决方案？
我喜欢这种方法的想法，我想知道谁使用这种方法，如果它运作良好。我喜欢的是，这样我可以继续懒惰，只是盲目地使用安装工具链，一切都应该正常工作，不需要对每个应用程序配置文件等进行任何特殊的修改来改变路径。
不同的应用程序很容易重用依赖项。 我用这种方法没有预见到的任何问题？是否有人使用此解决方案？
这可能是走的路吗？使用这种方法，我假设我应该在ONE Docker容器中安装我想要安装/试用的所有应用程序，否则我将通过在每个容器中复制依赖项来浪费存储空间？或者DOCKER或其他应用程序容器是否跨容器对文件/库进行重复数据删除？ 这对于docker / containers中的图形/ x-windows / etc应用程序是否正常？
如果你知道比Overlayfs / overlayroot或Docker / LXC更容易实现我想要的东西，那就不再需要设置麻烦了，请告诉我.tx
答案 0 :(得分：0)
经过进一步研究和测试/试用docker之后，我决定像docker这样的“容器”是安装以后可能想要清除的应用程序的简单方法。似乎这种技术已经在底层使用了Overlayfs overlayroot类技术来利用主机中已经安装的依赖项并在docker镜像中安装其他所需的依赖项。所以基本上我获得了与我所谈到的其他手动overlayroot技术相同的优点，但却无需设置所有这些。
所以，我现在是应用容器的信徒！甚至适用于GUI应用程序。
现在我可以保留一个非常轻量级的小型主根分区，只需安装我想要在app容器内部尝试的任何内容，并在完成后删除。
这也解决了延迟不再需要依赖的问题，如果在主要的/ / p上手动执行覆盖，我必须自己处理。