跟踪程序

Question

当我安装一个简单的程序时，它经常使用make && make install并且通常甚至没有卸载目标。

如果我想升级一个程序，假设它只是无缝地重写旧程序是标准协议吗？

我如何跟踪这些程序；大多数人是否只是“一劳永逸”，如果没有给出卸载目标，我是否必须手动删除所有内容？

Answer 1

将每个程序安装在专用的目录树中，并使用Stow或XStow使所有程序出现在公共层次结构中。Stow 创建从程序特定目录到公共树的符号链接。

更详细地说，选择一个顶级目录，例如/usr/local/stow. 下安装每个程序/usr/local/stow/PROGRAM_NAME。例如，安排将其可执行文件安装在 中/usr/local/stow/PROGRAM_NAME/bin，将其手册页安装在中/usr/local/stow/man/man1等等。如果程序使用 autoconf，则运行./configure --prefix /usr/local/stow/PROGRAM_NAME. 运行后make install，运行stow：

./configure --prefix /usr/local/stow/PROGRAM_NAME
make
sudo make install
cd /usr/local/stow
sudo stow PROGRAM_NAME

现在您将拥有如下符号链接：

/usr/local/bin/foo -> ../stow/PROGRAM_NAME/bin/foo
/usr/local/man/man1/foo.1 -> ../../stow/PROGRAM_NAME/man/man1/foo.1
/usr/local/lib/foo -> ../stow/PROGRAM_NAME/lib/foo

通过列出stow目录的内容，您可以轻松跟踪已安装的程序，并且您始终知道文件属于哪个程序，因为它是指向该程序目录下某个位置的符号链接。通过运行stow -D PROGRAM_NAME然后删除程序目录来卸载程序。您可以通过运行使程序暂时不可用stow -D PROGRAM_NAME（运行stow PROGRAM_NAME使其再次可用）。

如果您希望能够在同一程序的不同版本之间快速切换，请使用/usr/local/stow/PROGRAM_NAME-VERSION作为程序目录。要从版本 3 升级到版本 4，请安装版本 4，然后运行stow -D PROGRAM_NAME-3; stow PROGRAM_NAME-4.

旧版本的 Stow 并没有超出我在这个答案中描述的基础知识。较新的版本以及 XStow（最近没有维护）具有更高级的功能，例如能够忽略某些文件，更好地处理 stow 目录之外的现有符号链接（例如man -> share/man），自动处理一些冲突（当两个程序提供相同的文件）等。

如果您没有或不想使用 root 访问权限，您可以在您的主目录下选择一个目录，例如~/software/stow. 在这种情况下，添加~/software/bin到您的PATH. 如果man没有自动找到手册页，请添加~/software/man到您的MANPATH. 添加~/software/info到您的INFOPATH,~/software/lib/python到您的PYTHONPATH, 等等。

Answer 2

您可以使用checkinstall创建包（RPM、Deb 或 Slackware 兼容包）这样，您可以使用发行版包管理器添加/删除应用程序（但不能更新）

您可以checkinstall代替make install命令使用（对 Deb 使用 -D 参数；-R 是 RPM，-S 是 Slackware）：

root@nowhere# ./configure
root@nowhere# make
root@nowhere# checkinstall -D

checkinstall 将默认构建和安装包，或者您可以只构建包而不安装。

checkinstall 在大多数发行版存储库中可用。

Answer 3

在大多数情况下，这就是包、端口和其他类型的管理器阻止此类事情发生的原因。

我会说手动删除是手动安装的唯一方法，除非其他人对此有更好的答案，我可能不知道。

Answer 4

另一种选择来自Linux From Scratch 提示：

使用包用户进行更多控制和包管理

3 套餐用户
3.1 简介

这个方案的基本思想很容易解释。每个包都属于某个“包用户”。安装包时，您以此包用户身份构建和安装包，从而导致安装的所有文件都归包用户所有。因此，所有常用的包管理任务都可以通过使用标准命令行实用程序轻松完成。ls -l <file>例如，一个简单的会告诉您<file>属于哪个包 ，并且一个find -user ...命令允许您对属于某个包的所有文件执行操作，例如删除它们以卸载该包。

但是包管理并不是包用户所擅长的。由于软件包用户没有 root 权限，因此软件包的安装功能受到限制。例如，不允许包用户做的一件事是覆盖来自不同包用户的文件。想要安装同名二进制文件、库或头文件的不同包之间的冲突比您想象的要常见。对于包用户，您永远不会冒包 B 的安装会在您不注意的情况下悄悄破坏包 A 中的文件的风险。在安装包 B 期间每次尝试这样做都会导致“权限被拒绝”或“操作不允许”错误，以便您有机会采取适当的步骤。不允许软件包用户做的另一件事是安装 setuid root 二进制文件。制作二进制 setuid root 的决定也是谨慎的管理员不想留给软件包创建者的事情。

通常包用户帐户没有有效的密码，因此只有 root 可以su 访问包用户，这确保包用户不会打开其他方式进入系统并破坏安全性。但是您无论如何都可以设置密码，以允许您希望能够安装和维护某些软件包的共同管理员这样做，而无需访问实际的 root 帐户。例如，这个共同管理员可以安装、删除、更改他的工作组可能需要的其他库。但是，他将无法删除或修改不属于他/她的库，例如 libc。

在第一个粗略的建议之后，我发现了一个进化的变体：

crablfs——基于用户的包管理系统

这crablfs是使用独特的 uid 和 gid 进行包管理的包管理的最新样本，但在 sourceforge 上它又在 ulfs 中发展：

uLFS：从头开始的可管理和可重用的 Linux

对于已安装包的因果用户，我认为“包用户”LFS 解决方案是一种轻量级、侵入性较小且优雅的解决方案。简而言之，您在/usr/localor 中安装包/home/user/local并使用每个包的唯一 uid 和 gid 跟踪文件，但将所有文件放在传统位置、公共目录中/usr/local/bin，/usr/local/lib就像在所有主流 Linux 发行版中一样......文件阻塞和不需要的文件覆盖或删除Matthias S. Benkmann 在 more_control_and_pkg_man.txt 中解释了一个简洁的 Linux 技巧，它只需要普通的文件和目录权限操作，例如目录的粘滞位权限，以避免不需要的文件覆盖：

3.3 组

每个包用户至少属于 2 个组。这些组之一是“安装”组，所有包用户（并且只有包用户）都属于该组。允许包安装内容的所有目录都属于安装组。这包括 /bin 和 /usr/bin 等目录，但不包括 /root 或 / 等目录。安装组拥有的目录始终是组可写的。这对于包管理方面来说已经足够了，但是如果没有进一步的准备，这不会增加安全性或控制，因为每个包都可以替换来自不同包的文件（更改将在输出中可见）ls -l， 尽管）。出于这个原因，所有安装目录都获得了 sticky 属性。这允许用户创建新文件和删除或修改目录中自己的文件，但不能修改或删除来自其他用户的文件。在本提示的其余部分，每当使用术语“安装目录”时，它指的是属于组安装的目录，是组可写且具有粘性的。IOW，要变成<dir>你会做的安装目录

chgrp 安装 && chmod g+w,o+t

对我来说，它看起来是一个简单而聪明的解决方案！我在我的 LFS 构建中使用了这个方案，它是一个有效的解决方案......