如何将RPM中的目录标记为不再由RPM管理

Question

所以我有这个问题，在RPM的版本“1”中有一个符号目录。我们把它称为“/ foo”。为了澄清，“/ foo”在版本“1”的RPM中定义。在版本“2”中，我希望以编程方式在postinstall脚本中创建“/ foo”。但是当我从RPM的规范中删除“/ foo”时，它会在安装后的脚本已经运行后删除“/ foo”。有办法防止这种情况吗？那就是告诉RPM不要删除“/ foo”，即使它不再由RPM管理？

Answer 1

我认为你的意思是升级操作。如果是这样，RPM正在正确清理旧文件。您可以尝试将未注册的文件放入目录（通过%postinstall）。 “echo > /foo/.keepdir”或类似的东西。然后它可能会不管它，因为它无法识别文件，也不应该删除版本1的%files部分中未列出的文件。

但是，我会注意到，如果您创建并使用目录/foo，那么应该让您的包声明它，以便当某人出现并尝试“{{ 1}}“他们可以告诉它来自哪里以及谁使用它。

Answer 2

您可以在不使用/ foo的情况下创建RPM 1.1版，升级到1.1然后升级到2。

Answer 3

您可以使用%posttrans代替%post来解决此问题。但是请注意，posttrans scriptlet应该用纯粹的lua编写。这是因为除了RPM本身之外，它们理论上可以在kickstart中运行而不需要任何shell /库。

scriptlet的完整顺序（取自Fedora Packaging Guidelines）如下：

1. ％pretrans of new package
2. ％pre of new package
3. （包安装）
4. 新包裹的帖子
5. 其他软件包的％triggerin（通过安装新软件包启动）
6. 新包装的％triggerin（如果有的话）
7. 旧软件包的％triggerun（如果它是通过卸载旧软件包来启动的）
8. 其他软件包的％triggerun（通过卸载旧软件包启动）
9. ％preun of old package
10. （删除旧包裹）
11. ％postun of old package
12. ％packagepostun旧包（如果它通过卸载旧包启动）
13. ％triggerpostun其他软件包（如果它们是通过卸载旧软件包来设置的）
14. ％posttrans of new package

我会注意到，通常不建议在过境后进行任何复杂的工作。您在％posttrans中引入的任何问题在更新期间都很难修复。相反，您可以提供管理员应该在更新后运行的支持脚本。应用程序可以优雅地错误输出并提醒他们这样做（在某些情况下，我猜这是不可能的，但通常有一种方法可以很好地完成它）。或者应用程序本身可以根据需要检测到这一点并正确地符号链接/复制依赖关系。

Aand最后警告：RPM中存在一个问题，即处理更新，其中一个RPM具有符号链接到目录，而新RPM具有目录（或反转）。如果您看到交易错误，这可能是可能的罪魁祸首。这只能在％pretrans /％posttrans scriptlets

中修复

Answer 4

尝试将foo标记为spec文件的％files部分中的％config（noreplace）文件。这将使rpm在升级期间不会修改文件。