如何使用rpm更新/替换现有文件？

问题描述

我有几个我希望使用rpm部署的应用程序。我的应用程序部署中的某些文件会从其他已部署的软件包中覆盖文件。只需在部署包中包含新文件就会导致rpm冲突。

我正在寻找使用rpm更新/替换已安装文件的正确方法。 >

我已经提出了一些解决方案，但没有什么似乎是正确的。

• 维护包含原始文件的rpms的自定义版本。

这似乎是一个相当小的回报的大量工作，即使感觉

• 将文件以另一个名称包含在rpm中，并将其复制到文章中部分。

这将工作，但会意味着将系统与文件的多个副本进行乱抛垃圾。这也意味着每个文件的rpm构建规范的额外维护。

• 在文章中使用wget替换原始文件服务器。

这与复制技术类似，但文件甚至不会生活在rpm中。这可能是一个很好的中央配置权限。

• 将文件部署为新文件，然后使用符号链接覆盖原始文件。 li>
  

这也类似于复制技术，但是较少混乱。这里的问题是某些文件的表现不如符号链接。

解决方案

据我所知，RPM不是旨在允许更新/替换现有文件，所以你做的任何事情都将是一个黑客。

在你列出的选项中，我会选择＃1作为最糟糕的是，如果目标系统是我管理的系统（正如你所说，它是更多的工作，但是最干净的解决方案），并且＃2和＃4（符号链接在可能的情况下，副本在哪里）如果我正在创建其他系统的RPM（避免必须分发一堆RPM，但我会使文档中的非常清楚我在做什么）。

您尚未描述哪些文件需要更新或更换，以及需要更新的文件。根据这些问题的答案，您可能还有几个其他选项：

• 许多程序旨在使用单个默认配置文件并且还可以从 .d 子目录中获取配置文件。例如，Apache使用 /etc/httpd/conf/httpd.conf 和 /etc/httpd/conf.d/ *。conf ，所以您的RPM可以删除 /etc/httpd/conf.d 下的文件，而不是修改 / etc / httpd / conf / httpd的.conf 。如果您需要修改的文件是不遵循此模式但可以进行配置的配置文件，则可以向包维护者建议添加此功能;对于诸如 sendmail 和<$ c $的命令行实用程序，


• c> lpr 可以由多个包提供，替代系统（见 man alternative ）允许提供这些实用程序并排安装的1 RPM以上。再次，如果您需要修改的文件是不遵循此模式但可以进行的命令行实用程序，则可以向包维护者建议他们添加此功能。


• 通过或，而不是通过自定义RPM。我认为红帽有利于Puppet。


• 如果我创建了我不管理的系统的RPM，我会考虑使用Bitrock这样的第三方工具，并将所有的在 / opt 下的东西，所以我不必踩到其他管理员的RPM安装的文件。

I have several applications that I wish to deploy using rpm. Some of the files in my application deployments override files from other deployed packages. Simply including the new files in the deployment package will cause rpm conflicts.

I am looking for the proper way to use rpm to update/replace already installed files.

I have already come up with a few solutions but nothing seems quite right.

• Maintain custom versions of the rpms containing the original files.

This seems like a large amount of work for a relatively small reward even though it feels less like a hack than some of the other possible solutions.

• Include the files in the rpm with another name and copy them over in the post section.

This would work but will mean littering the system with multiple copies of the files. Also it means additional maintenance in the rpm build spec for each file.

• Use wget in the post section to replace the original files from some known server.

This is similar to the copy technique but the files wouldn't even live in the rpm. This might act like a nice central configuration authority though.

• Deploy the files as new files, then use symlinks to override the originals.

This is also similar to the copy technique but with less clutter. The problem here is that some files don't behave well as symlinks.

解决方案

To the best of my knowledge, RPM is not designed to permit updating / replacing existing files, so anything that you do is going to be a hack.

Of the options you list, I'd choose #1 as the least bad hack if the target systems are systems that I admin (as you say, it's more work but is the cleanest solution) and a combination of #2 and #4 (symlinks where possible, copies where not) if I'm creating the RPMs for others' systems (to avoid having to distribute a bunch of RPMs, but I'd make it very clear in the docs what I'm doing).

You haven't described which files need to be updated or replaced and how they need to be updated. Depending on the answers to those questions, you may have a couple of other options:

• Many programs are designed to use a single default configuration file and also to grab configuration files from a .d subdirectory. For example, Apache uses /etc/httpd/conf/httpd.conf and /etc/httpd/conf.d/*.conf, so your RPMs could drop files under /etc/httpd/conf.d instead of modifying /etc/httpd/conf/httpd.conf. And if the files that you need to modify are config files that don't follow this pattern but could be made to, you can suggest to the package maintainers that they add this capability; this wouldn't help you immediately but would make future releases easier.
• For command-line utilities like sendmail and lpr that can be provided by multiple packages, the alternatives system (see man alternatives) permits more than 1 RPM that provides these utilities to be installed side by side. Again, if the files that you need to modify are command-line utilities that don't follow this pattern but could be made to, you can suggest to the package maintainers that they add this capability.
• Config file changes on systems that you administer are better managed through a tool like Cfengine or Puppet rather than through custom RPMs. I think that Red Hat favors Puppet.
• If I were creating the RPMs for systems I don't administer, I'd consider using a third-party tool like Bitrock and dumping all of my stuff under /opt just so I wouldn't have to stomp on files installed by other admins' RPMs.

这篇关于如何使用rpm更新/替换现有文件？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！