在自定义安装以维护升级路径时，应遵循哪些准则？

Question

过去，我疯狂地自定义我的 Ubuntu 安装，但一旦时机成熟就无法升级它。那么如何在不遇到升级问题的情况下自定义安装呢？是否可以在不完全依赖 Ubuntu 软件库的情况下这样做？

Answer 1

使升级顺利进行的一个重要因素是不要做任何会使包管理器感到困惑的事情。也就是说，您不应该自己接触包管理器希望成为其域的系统区域。几个具体的例子。

如果您自己使用 ./configure 编译/安装程序；制作; make install 方法，不要直接放在/usr. 最好使用/usr/localor /opt，或者（甚至更好）滚动您自己的 deb 包。

删除软件包时，您可以执行正常删除或显式清除。除非您清除包，否则包管理器可能会将文件留在 下/etc，/var依此类推。不要自己删除这些文件，因为包管理器希望它们在那里。而是使用您的包管理器来明确清除包的剩余部分。

使用来自第三方存储库的 deb 包理论上应该是安全的，假设它们是精心构建的等等。但是，为了安全起见，您可能需要考虑在升级到新的 Ubuntu 版本之前删除这些包和/或存储库。

好的，让我看看我是否可以在这个答案中添加更多的肉...

首先，您在主目录中所做的一切对于包管理器来说都是完全安全的。它永远不会碰下任何东西/home。

（当然，你仍然可以通过对你的主目录做坏事来给自己带来很多混乱。幸运的是，通常可以通过从你的主目录中删除损坏的配置文件来恢复，并让它们在默认情况下重新创建下次使用。请注意，默认配置的自动重新创建仅适用于您的个人配置文件，而不适用于系统范围内的内容/etc）

作为（强大）桌面用户的角色，我猜最常见的系统范围的创造力将是安装额外的应用程序、库、emacs 模式等？同样，真正重要的部分是始终将 none deb 包的东西放在下面/usr/local而不是下面/usr；使用/usr/local/bin代替/usr/bin，使用/usr/local/share/emacs/23.1代替/usr/share/emacs/23.1等等。

一旦您开始使用服务器守护程序，您很快就会遇到/etc. 虽然您通常可以修改 下的文件/etc，但您“永远不要”实际删除那里的文件或目录，除非是您自己创建的。同样，您应该小心自己在那里创建新文件，以防它们稍后与包管理器想要创建的配置文件发生冲突。话虽如此，您肯定可以（并且应该）在/etc. 一个更常见的例子是在/etc/apache2/sites-available.

有时您可能希望在/var. 虽然它与 完全不同的地方/etc，但仍然考虑相同的规则，即谨慎行事并根据个人考虑做事。

如果您想了解更多信息，查看Filesystem Hierarchy Standard (FHS)或Debian Policy Manual不会有什么坏处。虽然回答你最初的问题可能完全是矫枉过正，但它仍然是一本好书。