Understanding Package Naming convention

Latest response

Hi, I am trying to understand the rhel package naming convention. Eg.

kexec-tools-1.102pre-126.el5_7.7.x86_64.rpm

I understand this is the software package "kexec-tools", software version "1.102", which is a prerelease, package version 126 (the 126th build of the package), for RHEL 5 (el5).
What I don't understand is the "_7.7" part. What does it tell me?

Best,
Isaac

Responses

Have a look at the (Fedora) naming convention at https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Release_Tag.
When you execute rpm -qi kexec-tools-1.102pre-126.el5_7.7.x86_64, you will see that the release is 02pre-126.el5_7.7. The "el5_7" means RHEL 5.7 and the ".7" means 7 minor release bumps for old branches.

I still don't understand the last number ".7" - if its even just a minor modification of the package (e.g. just a spec file update with comments), in my understanding the package release number should increment.

From the changelog entry of the specfile in the source rpm:

%changelog
* Thu Jan 12 2012 Amerigo Wang <amwang@redhat.com> - 1.102pre-126.7
- Remove the restriction for Xen HVM guests, resolve bug 772164.

* Fri Apr 29 2011 Amerigo Wang <amwang@redhat.com> - 1.102pre-126.6
- Add the missing part of the previous patch. Resolve bug 700636. 

* Fri Mar 04 2011 Amerigo Wang <amwang@redhat.com> - 1.102pre-126.5
- Get the backup memory region dynamically. Resolve bug 682085. 

* Thu Jan 13 2011 Amerigo Wang <amwang@redhat.com> - 1.102pre-126.4
- Add ext4 module. Resolve bug 667966.

* Wed Jan 12 2011 Neil Horman - 1.102pre-126.3
- Forcing brew rebuild

* Wed Jan 12 2011 Amerigo Wang <amwang@redhat.com> - 1.102pre-126.2
- Check fsck.ext4 binary before include it. Resolve bug 667966.

* Wed Jan 12 2011 Amerigo Wang <amwang@redhat.com> - 1.102pre-126.1
- Add ext4 support, from Dave Maley. Resolve bug 667966.

* Tue Nov 30 2010 Amerigo Wang <amwang@redhat.com> - 1.102pre-126
- Check cpuid only on x86, bypass other arch. Resolve bug 652500.

All bumps are made based upon "1.102pre-126".

In this example, 1.102pre is the upstream version, and 126.7 is the rpm package release. The rpm naming convention uses dashes to separate name-version-release. That page says, "The only restriction placed on the version is that it cannot contain a dash".

If you download kexec-tools-1.102pre-126.el5_7.7.x86_64.rpm, you can see the version and release numbers.

rpm -qi kexec-tools-1.102pre-126.el5_7.7.x86_64.rpm

Name        : kexec-tools
Version     : 1.102pre
Release     : 126.el5_7.7
Architecture: x86_64

The confusing thing is that the distribution tag (the 'el5_7' part) is sometimes stuck in the middle of the release string. Here for example, the major part of the release string is '126', the minor part of the release string is '7', and the distribution tag 'el5_7' is stuck in between the two.

The distribution tag el5_7 means "Packaged for RHEL 5.7".

Here's what the kexec-tools.spec that was used to build this rpm file would look like.

Name:         kexec-tools
Version:      1.102pre
Release:      126%{?dist}.7

For more on the RPM naming format, see the RPM Packaging Guide, especially the part about building RPMs

I would like to understand what exactly elX_Y means in relation to the target O/S version. The RPM Packaging Guide does not go into the sub-version (e.g., the _Y part) as far as I could see.

My thinking was that, e.g., "el7" by itself meant it could be used in any version of EL 7.x, but if it said "el7_2.whatever" then it could only be used in EL 7.2, but I don't think that is correct.

To use some specific examples of packages, there are these:

zsh-5.0.2-14.el7.x86_64.rpm
zsh-5.0.2-14.el7_2.2.x86_64.rpm
zsh-5.0.2-25.el7.x86_64.rpm
zsh-5.0.2-25.el7_3.1.x86_64.rpm

In each case of these versions is an el7 and an el7_x release. If the el7 version worked on any 7.x box we would not have the el7_x files. So out of the 4 files above, which would I expect to find on 7.2, 7.3, and 7.4 boxes?

nspr-4.11.0-1.el7_2.x86_64.rpm
nspr-4.13.1-1.0.el7_3.x86_64.rpm

Aside from trusting YUM, which of those should I expect to find in 7.2, 7.3, and 7.4 boxes? E.g., should I expect a 7.2 box to be running 4.11.0-1 and a 7.4 box to have 4.13.1-1.0.el7_3 installed?

I looked at several packages on my system:

  • tcpdump-4.9.0-5.el7.x86_64 - Came out as in 7.4.0 (a minor release)
  • systemtap-3.1-5.el7_4.x86_64 - Came out in 7.4.z (a z-stream errata)

I think the el7_4 notation is used for z-stream erratas. Fixes for a z-stream errata need to be built on the branch for the next minor-release before they are committed to the z-stream, but the minor release is typically released after the z-stream errata. Adding the _z notation is necessary so yum can always select the latest release.

Searching here for "z-stream" brought me to this page: https://access.redhat.com/solutions/44508

That page said that the underscore is the "Z-stream separator" and that the number after it is the RHEL minor version from which the package was forked. Underneath that is a diagram that shows a package with "el5_8" in its name, and a tag that simply says, "Enterprise Linux 5.8".

This has helped a lot, but there are still questions that remain, such as:

  • Is a package forked from 7.4 intended to only be for 7.4? Or should it work on 7.4 and later EL7 releases?

  • When a later release is simply named "el7" does that mean it works on all 7.x releases?

  • Looking at the available downloads and Change Log for systemtap I see only 7_4 package names, nothing with other minor versions like 7_2, and there are 7_4 releases that aren't even shown in the Change Log. I wonder why there isn't a systemtap-3.1-5_el7_2 and el7_3 as well as 7_4.

Any further thoughts on those questions?

Thanks for the tip about Z-stream.

Here is a stab at answering your questions:

  • A package forked from 7.4 will work in 7.4, and usually later EL7 releases. I say usually because a later EL7 release may have a dependency on a later version of the package. Usually these dependencies are included in the rpm. Yum and rpm will try to protect you.
  • When a package is named "el7", it means that it came from a Major or Minor release - 7.0, 7.1, 7.2, 7.3, or 7.4. It will work starting at whatever release it came out. It will likely work throughout RHEL7 releases, but see more on testing below.
  • Not all packages are updated for every minor release. They only receive a new build number when they are updated. There are 7 updates to systemtap in RHEL7: 7.0.z:systemtap-2.4-16.el7_0, 7.1: systemtap-2.6-8.el7, 7.1.z: systemtap-2.6-10.el7_1, 7.1.z: systemtap-2.6-10.el7_1, 7.2: systemtap-2.8-10.el7, 7.3: systemtap-3.0-7, 7.4: systemtap-3.1-3.el7, 7.4.z: systemtap-3.1-4.el7_4, 7.4.z: systemtap-3.1-5.el7_4
  • Systemtap was rebased for 7.4. This means that Red Hat switched to using a new upstream version of systemtap. Rebases usually happen at Major releases (such as RHEL-7), and sometimes Minor releases (such as RHEL-7.4), but never on z-stream.

Testing

Red Hat tests with packages from a specific release. So, if there is a 7.4.z fix, it will be tested with the latest build of packages from 7.4.z. Upgrading packages can be tested. But, there are too many combinations of package versions to test every combination.

Before a fix is made to a z-stream, it is first committed to the next Y-stream (Minor release). So upgrading a package shouldn't cause a regression.

Red Hat tests every package that it releases with a variety of environments, but your environment is likely to be different. Red Hat recommends testing updated packages before placing them in production.

Hope this helps.

https://access.redhat.com/solutions/401413 : "Red Hat does not require a system to be entirely composed of packages from a single minor release".

https://access.redhat.com/articles/rhel-abi-compatibility : "Compatibility level 2: APIs and ABIs are stable within one major release."

RHEL rpms for packages with compatibility level 2 (including systemtap) will not be updated as long as there are no changes in the software itself. When such an rpm has been generated for RHEL 7(.0) and RHEL 7.4 is current at the first update , the new rpm will indicate el7_4. No need for the "intermediate" el7_3 and el7_2.

https://access.redhat.com/solutions/401413: "Red Hat's independent software vendors (ISVs) may require that a system have packages installed solely from a single minor release for it to be fully supported by the software vendor."

Thank you Marc and Siem. Your answers are very helpful. Now I feel that I understand the full meaning and implications of the package names.

I have one new question and one clarification question to add to this conversation.

If I see a package that ends simply with el7.x86_64.rpm how do I know which EL release it is intended to run on without seeing the repository it came from?

Marc said that a package named "el7" came from a Major or Minor release and should, but might not, work in any EL7 release. Looking at python-perf, for example, EL7.2 had 3.10.0-327.el7 and now there is version 3.10.0-830.el7 available. Prior to this conversation, the "el7" naming made me think it was okay to put the newer release on a 7.2 box, and I want to be sure that I am understanding correctly that this is not okay because 3.10.0-830 was actually built on a EL7.4 system and could have dependencies on packages that are different in 7.4 than they are in 7.2. Is that right? This question is naturally closely related to the first one above.

The context behind me wanting to understand this thoroughly is just the situation Siem pointed out from solution document 401413 -- needing to stay on 7.2 to be supported by a vendor but also wanting as many security updates as possible.

Hi Angelo,

I just want to let you know that python-perf 3.10.0-830.el7 is from the rhel-7-server-beta-rpms repository.

The latest stable version of python-perf is 3.10.0-693.21.1.el7 from the rhel-7-server-rpms repository.

If you want to have the latest stable version of packages, you should disable the beta repository. :)

Regards,
Christian

Hi Christian. That's a good point, and I wouldn't want to do that. I just used it as an example from what I saw on the access.redhat.com/downloads/content/python-perf page from the Change Log. I didn't notice the Repo Label shown on the Details tab and didn't realise until now that they showed beta versions as being the "latest" until now. Thanks for pointing that out. I'll watch more closely for that.

You're welcome, Angelo ! :)

Regards,
Christian

My question is a bit different, what does the EL stand for? I'm guessing enterprise linux. With that, what does ES stand for?

EL stands indeed for Enterprise Linux. Does https://access.redhat.com/solutions/59290 answer your question concerning ES?

I'm not sure if the info on that page is still accurate, but I was finally able to get my patch installed.