Below is the quote from my textbook while explaining naming convention of a package (eg : packagename-a.b.c-x.arch.rpm).

Build No : The number following the version number (x) is the build number. Many distribution maintainers add a letter code to the build number to distinguish their packages from those of others. Note that these numbers are not comparable across package maintainers— George's build number 5 of a package is not necessarily an improvement on Susan's build number 4 of the same package.

Below is the quote while explaining upgrading of a package

Warning: It's possible to distribute the same program under different names. In this situation, upgrading may fail or it may produce a duplicate installation, which can yield bizarre program-specific malfunctions. Red Hat has described a formal system for package naming to avoid such problems, but they still occur occasionally. Therefore, it's best to upgrade a package using a subsequent release provided by the same individual or organization that provided the original.

Q-1 So as per quote-1; the build no. is associated with some letter specific to distro. maintainer, so it may fail to upgrade because of different name? & thus wont know whether its an upgraded version over current installation?

Q-2 But in case of same distro/name how does rpm decide whether its an upgraded version ? Does it parse the name of the package and pick the version-no from the name? If yes then why would it fail in case of different distro. as well ?


The build number is called a release. For example for python-qt5-5.10-3.fc28.x86_64, the name is "python-qt5" the version is "5.10" and the release is "3.fc28" and the last one is an architecture "x86_64"

What you call as George's or Susan's letter is usually called as a "dist tag". In the example above it is ".fc28". It is used to distinguish between different packages of the same version and release. For example python-qt5 for Fedora 28 puts files into /usr/lib64/python2.7/site-packages, but this will not work on RHEL6 as it expects python modules in /usr/lib64/python2.6 directory. So RHEL6 version of the same package is python-qt5-5.10-3.el6.x86_64

RPM itself compare just the name, version and release. There is no logic that you cannot install Fedora 28 package on RHEL7. It usually does not work, because of other dependencies. For example if you try upgrade your python-qt5-5.10-3.fc28.x86_64 with python-qt5-5.10-4.el7.x86_64 it will likely not work because of different SONAMEs of libQT*.so on RHEL7. But if you do that with some package, which does not have any requirements (or very relaxed requirements), then rpm itself will allow the upgrade because "4.el7" is bigger than "3.fc28". The problem is that author of the rpm package does not intend (nor tested) to install his package on a different platform. Rarely it does work but mostly does not.

  • So there is no meta information inside the package used by rpm to do installation or upgrade ? its just the name of the package file through which it decides whether its an upgraded version then the currently installed software ? – LoveWithMaths Apr 15 '18 at 17:36
  • but this will not work on RHEL6 as it expects python modules in /usr/lib64/python2.6 directorya why does red hat expect it to be in that specific directory ? – LoveWithMaths Apr 15 '18 at 17:41
  • Yes. RPM only compare NEVRA (name, epoch, version, release, architecture) to do the upgrade. If you are precise then Provides and Obsoletes play some role too, but it is just small technical detail. – msuchy Apr 16 '18 at 5:32
  • Because RHEL6 have python 2.6 which expect this path. RHEL7 and Fedora has python 2.7. – msuchy Apr 16 '18 at 5:33
  • RPM only compare NEVRA (name, epoch, version, release, architecture) to do the upgrade. But i can name the package whatever i like. In that case how does rpm figure out the upgrade. ? – LoveWithMaths Apr 21 '18 at 6:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.