0

I'm creating an RPM file (with rpmbuild). Currently it is possible to install several versions of the RPM in parallel (apparently RPM doesn't prevent this), but this causes problems because my %pre and %post scripts create and delete some files, so multiple parallel installations will conflict with each other.

Is there a way to prevent such parallel installation when building an RPM?

The package is intended to work on CentOS (RHEL) 6.

oliver
  • 6,204
  • 9
  • 46
  • 50

2 Answers2

0

Write %pre and %post scripts that can handle this (they are given an argument which indicates how many versions of the package will be installed when the transaction is finished).

Alternatively, you could try to conflict with all older versions of your own package. That might work.

Etan Reisner
  • 77,877
  • 8
  • 106
  • 148
  • I have now added a conflict to all older and all newer versions of the package. Not sure if that's "correct" but it seems to work fine. – oliver Mar 02 '15 at 13:51
  • You shouldn't need forward conflicts since the older version conflicts in the newer package should handle that... I think. But having conflicts in both directions shouldn't hurt I don't think. – Etan Reisner Mar 02 '15 at 16:19
  • Can you give an example? – CivFan Oct 19 '16 at 19:02
0

There is no need to prevent parallel installation, since the RPM database (or YUM) would be busy when a concurrent request was given. But if your package creates files which are not part of the "%files" listing, then you have to provide for installs, uninstalls and upgrades.

For upgrades, you need a consistent versioning scheme: a "newer" package has to have a "higher" version number. Given that, your spec-file has to have provision for checking the different modes (install, uninstall and upgrade). Details for that are in RPM upgrade uninstalls the RPM, which seems to be lacking a concrete example.

Community
  • 1
  • 1
Thomas Dickey
  • 51,086
  • 7
  • 70
  • 105
  • With "parallel" I meant that I can have two versions of the same RPM installed on the same system at the same time. That is, I do "rpm -i mypackage-1.0-1.x86_64.rpm" and then "rpm -i mypackage-2.0-1.x86_64.rpm", and then both packages are installed. My software cannot easily cope with this situation, so I'd like to prevent it in the first place. – oliver Mar 02 '15 at 09:38
  • With CentOS 6, you can install packages with either `rpm` or `yum`. I recall that it is possible with `rpm` to end up with multiple versions installed. However, using `yum` (and a consistent versioning scheme - you did not give detail) I have not seen `yum` result in multiple versions. – Thomas Dickey Mar 02 '15 at 09:43
  • Here are a couple of links discussing problem in trying to install multiple versions: http://stackoverflow.com/questions/22425839/how-to-install-two-different-version-of-same-package-with-yum http://serverfault.com/questions/106993/rpm-packaging-multiple-versions-for-simultaneous-install (as long as the packages have the same *name* and `yum` can determine that the versions are related, it will decide which is "newer" based on the version numbers). This link shows someone using different package names to get multiple versions: http://lists.baseurl.org/pipermail/yum/2007-May/020910.html – Thomas Dickey Mar 02 '15 at 09:45
  • When `yum` is available, it is the preferred method of installing, to avoid confusion between different databases used. – Thomas Dickey Mar 02 '15 at 09:47
  • @oliver: Shouldn't the next installation be an upgrade on the package instead of an installation? i.e: `rpm -Uvh mypackage-2.0-1.x86_64.rpm` – kaizenCoder Mar 03 '15 at 03:47
  • On the command line, if one says "yum install foo.rpm", yum looks at the package's version (seen for example with "rpm -qip foo.rpm"), and then at its database, to realize that you are updating a package. If you put foo.rpm in a local yum repository, then "yum install foo" will not necessarily do that -- you would have to do "yum upgrade foo" to ensure similar behavior. (I usually do one or the other, "yum upgrade foo.rpm" hasn't been that successful). – Thomas Dickey Mar 03 '15 at 09:16