Versioning differences for the same package

Iam abit confused about php version
PHP vendor website its php-8.0.30
Almalinux 8.8 repo its php-8.0.30-1

what does the “-1” mean for the Alma php version? are both versions the same?

It is customary for distributions to tweak software they package, to integrate it into distribution-specific ways of doing things, add or backport fixes or features, and so forth. In addition to the Version, RPM packages have a Release representing the release-version of the packaging in the distribution. If, for example, a distribution adds a new tweak to their package, but uses the same base upstream version of the software, the Release can be bumped, e.g. to -2, without changing the Version.

You can look at the differences between the upstream version and the RPM version in the source RPM, in your case, https://repo.almalinux.org/vault/8.8/AppStream/Source/Packages/php-8.0.30-1.module_el8.8.0%2B3655%2B3335cff6.src.rpm, wherein you will find the base upstream version being used, any patches that are being applied, and the build configuration.

So you mean AL added some fixes or features to integrate php-8.0.30 into the distribution and because of those additional fixes or features we got php-8.0.30-1. Where can I read more about the details of the additional fixes or features of php-8.0.30-1?

In the source RPM I linked.

Will I notice any differences between the upstream version and the RPM version in the source RPM in case I install either one of them? will I get any errors if I install php-8.0.30 in AL? or it will function just like php-8.0.30-1?

One can start with the changelog, which is in the package, rather than going directly to the sources. Last of it for php:

$  rpm -q --changelog php | head -23
* Fri Oct 06 2023 Remi Collet <rcollet@redhat.com> - 8.0.30-1
- rebase to 8.0.30
- Resolves: RHEL-11946

* Fri Jan 13 2023 Remi Collet <rcollet@redhat.com> - 8.0.27-1
- rebase to 8.0.27

* Mon Aug 01 2022 Remi Collet <rcollet@redhat.com> - 8.0.20-3
- snmp3 calls using authPriv or authNoPriv immediately return false #2104630

* Mon Jun 13 2022 Remi Collet <rcollet@redhat.com> - 8.0.20-2
- fix patch41 not applied (use system nikic/php-parser when available)

* Mon Jun 13 2022 Remi Collet <rcollet@redhat.com> - 8.0.20-1
- rebase to 8.0.20 #2095752
- clean unneeded dependency on useradd command #2095447
- add upstream patch to initialize pcre before mbstring
- retrieve tzdata version from /usr/share/zoneinfo/tzdata.zi

* Wed Dec 15 2021 Remi Collet <rcollet@redhat.com> - 8.0.13-1
- rebase to 8.0.13 #2032429
- refresh configuration files from upstream

As you see, the release 1 may be “just a rebase”, i.e. the upstream version, but may include something extra too.

Base ideology of EL is that it maintains its own forks/branches for what it provides.
Furthermore, the default is to use what the distro offers, because use of third party is all on you.
Are there differences? Depends.

If you look at kernel that is in RHEL 7 now, it is totally different beast from the upstream kernel 3.10.0 that did live briefly a decade ago.
The php seems to rebase often and have less differences.

1 Like

I agree with jlehtone that it is likely that the php RPM is on the opposite end of spectrum from kernel in terms of differences from upstream, i.e. that it is indeed likely to function so closely to php-8.0.30 that you wouldn’t notice any differences. Ultimately, however, if you must know, you need to extract and inspect the contents of the source RPM, because that is what tells you what went into the binary RPM.

If I take your second question as written, about installing the upstream version instead, you could certainly do such a custom local installation, but if you’re doing so to avoid having a less vanilla installation of PHP, you’d have it backwards, as you will have a much more expected/normal/typical installation of PHP on EL (Alma, Rocky, CentOS, RHEL, whatever) by using the RPM, whereas whatever you wire up yourself to make upstream PHP work with the other software in the operating system is likely to have quirks of your own making which no one else in the world will have experience with and be able to have written posts about or help you with.

If you do a custom local installation, you will also be losing the release engineering that is being done for you by the packager. Do you really want exactly php-8.0.30, or do you want php-8.0.30 plus security updates that arrive with a simple dnf update instead of having to make sure you repeat your custom installation process every time upstream does a release?

1 Like

Thank you jlehtone and quartsize for your very informative replies