跟踪程序

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

如果我想升级程序，是否假定它只是在旧程序上进行无缝重写是标准协议吗？

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

将每个程序安装在专用的目录树中，并使用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（最近尚未维护）具有更高级的功能，例如能够忽略某些文件，更好地处理存储目录之外的现有符号链接（如man -> share/man），自动处理一些冲突（当两个程序提供相同的文件），等等。

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

您可以使用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。

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

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

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

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

3软件包用户
3.1简介

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

但是，软件包管理并不是软件包用户所擅长的全部。由于软件包用户没有root权限，因此软件包的安装受到限制。例如，不允许包用户执行的一件事是覆盖其他包用户的文件。想要安装同名二进制文件，库文件或头文件的不同软件包之间的冲突比您想象的要普遍得多。对于程序包用户，您永远不会冒着程序包B的安装而无须注意就无提示地破坏程序包A中文件的风险。在软件包B的安装过程中，每次尝试这样做都会导致“权限被拒绝”或“不允许操作”错误，以便您有机会采取适当的步骤。程序包用户不允许执行的另一件事是安装setuid根二进制文件。做出二进制setuid根的决定也是谨慎的管理员不想让软件包的创建者承担的事情。

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

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

crablfs-基于用户的包裹管理系统

这crablfs是使用独特的uid和gid进行软件包管理的软件包管理的最新标本，但是在sourceforge上，它又以ulfs的形式发展：

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

对于已安装软件包的因果用户，我认为“软件包用户” LFS解决方案是一种轻量级，侵入性较小且美观的解决方案。简而言之，您将软件包安装在/usr/local或中，/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构建中使用了该方案，这是一个可行的解决方案...

1. 您可以将空RPM用作提醒。
2. 您可以考虑将软件正确包装到RPM中。
3. 您可以保留tar安装文件的副本/usr/src/non-rpms以提醒您（我通常这样做）。