Topic: yum can instal only packages with the number php80, I cant update

yum can instal only packages that include the number like php80 but if I try to update & install it offers me the same list of updates with their default names for example php instead of php80. These updates always fail with the generic error "dependencies problems" when I dig through the output of the yum command to find the dependencies I need to install it tells me nothing about what is missing.
What am I missing.
RHEL 7.9
PHP 7.4.33
I am not a typical server admin, my experience is limited.

Re: yum can instal only packages with the number php80, I cant update

1/ RHEL 7.9 is close to its end of life in 8 months (June 2024)

I recommend to use a more recent version, RHEL 8.8 or 9.2

2/ Repository usage

For a proper repository configuration and usage, I recommend reading the FAQ
Especially https://blog.remirepo.net/pages/English-FAQ#scl

And to follow the Wizard's instructions
https://rpms.remirepo.net/wizard/

3/ more information

what is your goal?
which command do you run?
full output?

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: yum can instal only packages with the number php80, I cant update

Thanks I found the whole update was blocked by one piece of software that apparently no longer has some of its dependencies available, PHP PECL infobase I believe. I deleted it because it wasn't needed then the update succeeded.

BUT after the update none of my web forms work so I had to revert to the latest snapshot. It is so wonderful that PHP has decided to change how it's basic code functions every update. Backwards compatibility is for wimps and I so love to be psychologically tested to my breaking point every PHP update.

It has something to do with NULL value being passed to a function in the local part of my recaptcha script. I think that issue must start somewhere else in the many pages of code that I have processing forms but so far the only error I get from PHP is:
Deprecated: stripslashes(): Passing null to parameter #1 ($string) of type string is deprecated in /var/www/html/templates/recaptchalib.php on line 80

Re: yum can instal only packages with the number php80, I cant update

Still don't know what are your goals...


BTW "deprecations" in minor version are only informational
about what will be an "error" in next major version

Obviously, upgrades have to be tested in dev/test environment
and usually, libraries / applications may also require an update

This is the reason why the repository provides each minor version
in a separate stream (or repo), and why it is always an admin choice


I don't think I can help more.

> I am not a typical server admin, my experience is limited.

You need experience, or perhaps a real sysadmin wink

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: yum can instal only packages with the number php80, I cant update

You are probably a good and helpful guy so this wisdom is not personal, and I would love it if you could pass this up hill.

I have been working in tech for about 30 years but I have so much to do that I only have a few days a year to focus on the 3 servers that were added to my job when our server person retired about 8 years ago.  For most of those 30 years most software makers understood well the concept of backwards compatibility, it was a big selling point but more than that it was understood as the only logical way to make software.

Without backwards compatibility you are breaking things that the people your product serves worked on very hard to make and you are breaking those things for zero logical reasons. PHP’s creators can easily choose to security patch the PHP code functions that people use right as they are, BUT instead of helping the people who use PHP they choose to break the code users make and need to maintain. I have heard people make the argument that they change the way code works so that the code has internal logical consistency, but you have to know you are not serving the code, you are serving the people who use the code, if you choose to change the way code functions for internal logical consistency you are hurting real hard-working people.
&
I guarantee that a very significant number of those people are like me struggling to find time just to get the updates done at all making it that much more of challenge to debug code that up until the moment of upgrade was working perfectly.

You must see that the real-world effect of that is to make many people avoid updating PHP as long as possible and that makes overall internet security worse WORLDWIDE.

Sorry if I said this in any way that hurts you personally this is something beyond either of us that just needs to be said.
Thanks, Gary

Re: yum can instal only packages with the number php80, I cant update

Again, I don't know what is your goal.

PHP dev try to maintain BC in minor version, deprecation exists to inform about change in next Major version
Everything is documented in new version release notes
Every change is described in RFC and vote
PHP is a free community project
PHP users are expecting language improvements, and PHP is an active project, so this happens.

If you want your voice to count, you must be involved in the project.

Now, I you want stability, keep the same minor version.
(even EOL versions received security patches in my repository)

But yet, updating to a newer version may require more work than a simple update
And AFAIK this is true for most active languages (php, python, java, c++...)

Again I don't know what is your goal, update from which version to which new one, why, ... and nothing about what app are running.

But definitively, from my experience, update to minor (ex: 8.1 to 8.2) are usually simple, only few deprecation which are good to fix
and update to major (ex: 7.x to 8.x) require more work.

Again everything is documented https://www.php.net/manual/en/appendices.php

You must ensure that your app is compatible "before" updating
so running a dev/test env
And if your app is not compatible, ask its provider for an update, or your developers.


BTW, again, I don't think I can help more, it will be off topic here
These forum are for users of my repository, and about RPM installation/usage, not about general PHP issues

Lot of other resources are available for PHP users.

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi