| Summary: | Unmask PHP_TARGETS for 8.2 (php_targets_php8-2) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | mentalstring <mentalstring> |
| Component: | Stabilization | Assignee: | PHP Bugs <php-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | bertrand, flow, mjo, mmk |
| Priority: | Normal | Keywords: | PullRequest |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://github.com/gentoo/gentoo/pull/34967 https://github.com/gentoo/gentoo/pull/36919 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 920701 | ||
| Bug Blocks: | |||
|
Description
mentalstring
2023-11-30 10:41:14 UTC
I'll probably get to this eventually, but the delay is due to me being the only one maintaining PHP at the moment. And my personal interest in "PHP" doesn't extend far past dev-lang/php. Stabilizing 8.2 and the associated USE flag (php_targets_*) involves a bunch of extensions as well, and those are all currently unmaintained. To ensure that the flag changes don't break anything, we need at the very least a github PR that will trigger a full CI run. Understandable — and kudos for doing that single-handedly! The CI run sounds sensible, but I wouldn't know where to start — my knowledge of portage inner-works and is pretty superficial, so I'm not of much help. Plus, like you, my interest is mainly on PHP itself and only a couple of extensions. I suspect that's the most common scenario. With that — and I apologize if this makes no sense at all —, this means that perhaps not so used extensions are blocking PHP 8.2 which is what most need: would it make sense (assuming this is feasible) to stabilise PHP 8.2, while not updating the extensions to support php8-3 (USE_PHP="php8-0 php8-1"), and leave the test task to those who actually use them? (In reply to mentalstring from comment #2) > > With that — and I apologize if this makes no sense at all —, this means that > perhaps not so used extensions are blocking PHP 8.2 which is what most need: > would it make sense (assuming this is feasible) to stabilise PHP 8.2, while > not updating the extensions to support php8-3 (USE_PHP="php8-0 php8-1"), and > leave the test task to those who actually use them? Here's the catch: I don't know :) The last time I did it myself was when we moved from php-5.4 to php-7.0. Another developer handled every transition since then, and my memory isn't that good. It's possible (maybe even likely) that something breaks by stabilizing only dev-lang/php:8.2 without the corresponding PHP_TARGETS. The best way to detect it would be to submit a PR on github -- that will automatically trigger a CI run that sanity checks every package in the tree. But at that point we might as well stabilize the PHP_TARGETS, too, and let the CI detect any issues with the whole thing. It's really not that much work, a few hours at most. It's just one of the least pressing problems I have right now. If anyone else wants to take a shot at it, please consider it open season. After looking into this, I believe what should happen is 1. unmask PHP 8.2 (See https://github.com/gentoo/gentoo/pull/34967) 2. Add USE_PHP="… php8-2" to packages that do not have it yet 3. stabilize PHP 8.2 (bug #920701) So this bug (unmasking PHP 8.2) is blocking bug #920701. I don't see a reason why we should not make the first step and unmask PHP 8.2 now. @mjo: as last remaining member of the PHP team, please correct me if I am wrong. Anything holding us back to go forward with this? It would be really nice to have a stable PHP-8.2 target. (In reply to Michael Mair-Keimberger (iamnr3) from comment #5) > Anything holding us back to go forward with this? It would be really nice to > have a stable PHP-8.2 target. dev-lang/php:8.2 is stable now, and the TARGETS flag is unmasked where possible. What's missing? (In reply to Michael Orlitzky from comment #6) > (In reply to Michael Mair-Keimberger (iamnr3) from comment #5) > > Anything holding us back to go forward with this? It would be really nice to > > have a stable PHP-8.2 target. > > dev-lang/php:8.2 is stable now, and the TARGETS flag is unmasked where > possible. What's missing? On my stable system i got dev-lang/php:8.2 already a while ago, but I can't use it yet because package's like dev-php/pecl-imagick and dev-php/pecl-apcu are still build against php8-1 (PHP_TARGETS) Now i can set PHP_TARGETS myself in make.conf but i usually try to avoid that and go with what is the default. Not a big deal for me, but i guess since php:8.2 is stable so could be PHP_TARGETS too? (In reply to Michael Mair-Keimberger (iamnr3) from comment #7) > Now i can set PHP_TARGETS myself in make.conf but i usually try to avoid > that and go with what is the default. > > Not a big deal for me, but i guess since php:8.2 is stable so could be > PHP_TARGETS too? It should be relatively safe to switch the default now. Open a PR? If the CI says it's OK, it's OK by me. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=52bed2676755bd367ded48a020d19b763d5ba0ac commit 52bed2676755bd367ded48a020d19b763d5ba0ac Author: Michael Mair-Keimberger <mmk@levelnine.at> AuthorDate: 2024-05-31 13:36:35 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2024-06-01 12:41:53 +0000 profiles/base: make.defaults: switch PHP_TARGETS to php8-2 Closes: https://github.com/gentoo/gentoo/pull/36919 Closes: https://bugs.gentoo.org/918893 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> Signed-off-by: Michael Mair-Keimberger <mmk@levelnine.at> profiles/base/make.defaults | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) |
