Suppose I have an already installed RPM package on my system. I want create another package which can overwrite some files of that existing package. How could I do that? Note that this is not an upgrade. Simply some modules (packaged in RPM) share some configure files. Each time a module is updated, the configure files needs to be updated as well. All modules share the same configure files.

Do you have rpmbuild installed? That tool should solve your problem.

Of course I do have rpmbuild. However, the problem is, I have to build 2 packages, both packages share the same config files. In fact, each has their own physical config files of the same type, and each time a package is update or freshly insall, the config files of that package are gonna be replaced by the current config files of the other package, and both packages will use the latest config files.

You can consider each time a new module is install, the latest config files will replace the current config files which is used by several other rpm packages in the system. RPM seems to not allow it. I don't know how to overwrite or delete the old config files correctly. If I left it there, the new config files can' be installed because of conflicts (other package is using).

I am not sure - can rpm2cpio help: http://www.rpm.org/max-rpm/s1-rpm-mi...-rpm2cpio.html ?

From 'man rpm' : --replacefiles http://linux.die.net/man/8/rpm


Suggest : Use this command for the "update" :
# rpm -Uvh --replacefiles <package>.rpm

..

Apart from what is generated on the fly in say a %post or created by a user, systems using RPM package management consider configuration files integral parts of a package if it's in the %files list. As official RPM packages do not, consider replacing a binary, library or configuration file owned by one package with that of another package as a design stage mistake. If your packages are only meant to destroy your own systems I'd say go right ahead. But if you are going to distribute them the answer must be "no": use another method of integrating changes. (BTW as you carefully avoided posting any specifics and examples there's no way telling what will work.)


You're correct to voice doubt here as using 'rpm2cpio' is a good way to fsck up a system managed with RPM: it bypasses the standard install method and any such changes won't be visible to the RPMDB (OK, unless you use "--justdb" afterwards). Avoid.


Use of --force, be it --replacefiles or otherwise, is yet another way to b0rk a system managed with RPM, in this case by overriding sanity checks. Best avoid.

2 members found this post helpful.

In my system, it requires to use rpm. So there's not other system allowed here. The situation is like this:

Suppose I have 3 modules, which is three binaries files to put in a /opt/boot/ folder (this is a custom folder). In order for the system to load all the modules, it needs to read in a configure file like this:

Initially, I will have to create 3 rpm packages to install in the system. Each will packaged with the same configure file, with new content. Each time a module is updated, a new binary needs to be replaced. Consider I have an updated module1 which is mod1.bin.verA2, I need to create an rpm package to upgrade the existing package. The update package will contain the binary file and the new configure file with content like this:

After a patch, a new configure file with new updated module are replaced. However, the problem with this is, even after the installation of the first module, the second package will cause conflicts and won't be installed properly. Same happens for upgrading (different packages update the shared configure files).

I am thinking of separting the configure files and the modules into two separated packages, and each time an upgrade occurs, there will be two packages released, one for configure file and one for binary files. I will need to propose this idea and wait for acceptance though, because the above method is a requirement..

1 members found this post helpful.

If I understand your post correctly you should use %config(noreplace). Updating a package then forces a %{config}.rpmnew to be created. The admin then can 'diff -Urn %{config} %{config}.rpmnew > %{config}.diff', review changes and use say 'patch' to make them stick. Hindsight, true, but if loading order was a requirement it might have been better had configuration loading been incorporated in the design phase. For example daemons these days often use a /etc/%{name}.d/ directory and allow separate uniquely numbered configuration files to be placed there to preserve loading order. If redesign isn't possible (;-p) another way could be to regenerate the configuration file in %post based on RPMDB output? See querying the RPMDB using say 'rpm -q %{name} --qf="%{NAME} %{RELEASE} %{INSTALLTIME}\n"|sort -k3'. And if 'at' is running this could even be handed off as a job in a %post scriptlet to ensure any ops are done after RPM transactions are completed.

2 members found this post helpful.

This seems promising. I will try it soon. However, I'm not sure if it applies to multiple packages sharing same configuration files, since the method only considers the case for single package only.

Given each packages .spec file contains lines like "%define name module1" and "%define version verA2", as long as you update packages the RPMDB can be queried for all packages with "^.*%{name}.*" in it, etc, etc. When ready post your proposed scriptlet (preferably between BB code tags) and we'll look at it.

???????????????

I meant to convert RPM o CPIO archive, and the latter can trivially be converted into a regular directory tree, and in the latter a file can be trivially updated.

Heh, that actually would be trivial and irrelevant to the OP's actual question. As far as I understand what he wants, that is.