Score:-3

Why PHP package versions in 22.04 are so screwed? (and why PHP package version are always screwed)

co flag

Today, I was wondering:

Why if I install php-fpm which is nowadays a key package for many PHP installations, Ubuntu 22.04 completely screws up the whole PHP install pretending to install weird versions like php8.1-common 8.1.2-1ubuntu2.9 instead of staying in 8.1.2-1ubuntu2??

One could say: just hold them. But why? Who takes this decisions of moving packages this way? How can be reverted?

This is just a philosophical question about Ubuntu, that has always perturbed me.

Probably 99% of the people are using a different repo like ondrej one for PHP that is more cohesive and is the go-to in most cases for serious people. But still wondering why the Ubuntu team is so odd to select this kind of packaging so weirdly for so long. This has been happening for AGES.

I'm also wondering if there is a better place to ask these things with the people responsible of this decision.

Levente avatar
cn flag
I find this question amazing, and as a person somewhat invested in php, am genuinely curious to find out the answer. My go-to idea of "just go for a preconfigured Vagrant Box, perhaps Laravel Homestead specifically" demonstrates that there is a valid frustration. That's why I point out that I find the wording of the question title quite rant-y for the preferences of this community. Possibly your question could invite more helpful contributions if the title was less emotionally loaded...
user535733 avatar
cn flag
"*Why...install...php8.1-common 8.1.2-1ubuntu2.9 instead of staying in 8.1.2-1ubuntu2??*" A momentary check of the changelog reveals that the "weird" versions are often security updates. Staying on the older version means published open vulns left in place. That would be, um, not desirable.
user535733 avatar
cn flag
-1: This question seems merely a rant as currently written. Happy to retract if edited into a useful, answerable question. You might be asking about how deb package versioning works between releases, or maybe not. It's hard to tell what you are asking.
SirLouen avatar
co flag
@user535733 in fact you have answered me
Score:-1
co flag

Thanks to the answer of @user535733 and a Discussion I had with some people in the group of #KUbuntu in Libera some days ago, now I think have the answer to my own question:

Ubuntu philosophy is to live away GNU ecosystem, but using GNU ecosystem.

Allow me to explain: If KDE for example, moves to 5.26 and leaves 5.24 for LTS, Ubuntu decides to be careless about KDE decisions (that are the real maintainers of such package) and prefer to downstream patches to the version they have to settle down (lets say 5.25 or 5.23 or whatever version they are at the moment of the settlement)

Their argument is: Ubuntu aims to keep offering super stable versions for every single package. This could make sense in LTS Ubuntu versions, and it would be even wiser to be aware of the official package maintainers LTS decisions and stick to them (sometimes they do and sometimes they don't).

But their mindset is to stick to whatever version they decide, regardless of the upstream decisions, something that is weird because many packages have lost maintenance (for example KDE 5.25) and now all new patches are being implemented in 5.26. They argue that the latest version is less stable that 5.25 because it's newer, but since it their primary patch focus, it always leads faster to an stable position that the previous, now unstable version (in this example 5.25) because they will be solving issues in 5.26 that still occurs in 5.25 (because ultimately each piece of software doesn't matter if it evolves the version, it will carry many issues from version to version).

But Ubuntu maintainers, have to do a double-effort to patch 5.25 with some of the patches they find in 5.26 KDE bug tracker. And they have to do for every-single-package!!! Ubuntu maintainers are doubling the job of hundreds, if not thousands of packages. Its completely nuts.

And all of this gigantic effort just to live in an illusion of stability, and proof is exactly this one: I keep finding bugs that higher versions of certain packages have already solved, but Ubuntu maintainers have not patched yet downstream in their theoretically lower and more "stable" versions (which are no more stable because they have more bugs than the upstream ones).

To sum up, they create non-official versioning of each single package, like what is happening from ages with PHP.

Considering that PHP has like 20 modules, one module like in this current case, FPM, happens to step in a lower version forget to move up versions of certain extra packages, and we end with a system with 12 packages held up indefinitely and having to tweak the upgrading systems to avoid constant unneeded warns and infos that could be an important thing to read in certain real situations.

Some users could say that this is an answer-rant.

But this is a little explanation to myself, to put a little context so I can understand better why the real solution for this is technically what I said in the former question: simply use a better repository for each package. In this case, PHP repo has been a synonym Ondrej since the beginning of the times.

And a side not for me, in case I stumble into the same question in a couple of months (I have a bad memory). For KDE and the liking, I should always stick to Ubuntu backports repo that has the upstream versions generally.

muru avatar
us flag
Your definition of stable is not their (or most distribution maintainers') definition of stable. To them, stable is (relatively) unchanging - a set of software with known behaviour. Your definition of stable is (relatively) "bug-free", but at the cost of changing things in a release. Distributions like Debian, Ubuntu, RHEL, CentOS, etc. prioritise the first definition.
SirLouen avatar
co flag
@muru yeah they are now in 8.1.2-9 and 8.1 is currently on mainstream in 8.1.13. Do the math but I don't see many extra refinements between 2+9 and 13 (2 extra changes and probably 1 or 2 unresolved bugs that Ubuntu downstream maintainers have not spotted yet)
muru avatar
us flag
And? Have you done the math on how long it takes to test things? The math on how often upstream makes patch releases? When there are multiple patch releases in quick succession as might happen sometimes, what math makes sense - uselessly release packages for each, or roll multiple patch releases into one package update? Do the math yourself.
SirLouen avatar
co flag
@muru I don't agree. Upstream solve issues and make version more stable. At the same time certain distributions are branching to one previous version and simply backporting. For further features, upstreams will launch a different major version, like 8.2 for PHP. So I clearly understand that bugs are being repaired twice: once from the upstream and twice from package maintainers in some distros like Ubuntu. Now I have one question: Does exist a distribution that stick with my idea? Or all distros work this way?
muru avatar
us flag
Of course you don't agree - didn't you read my first comment where I explained that your definition of "stable" is not what they're using? Pick any rolling release distro if you always want the latest packages. Gentoo, Arch, etc.
SirLouen avatar
co flag
@muru problem with RR is that they are in the latest versions, like PHP 8.2 straight. I prefer to stick to stable version say in this example 8.1.X, but real stable version (8.1.13 not 8.1.2-whateverX), like the ones that are being maintained by the upstream devs, not the ones chosen from a distro committee. I wonder if this exists at all.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.