Remove php provides with a version, replace with providerPriority #34680
Conversation
In all the php-8.*-*.yaml files: 1. replace all of the 'phpMM' definitions with simple var rather than transform based name. 2. replace any virtual provides with a version with an empty version and set providerPriority to a value based on the PHP version (instead of package version). This takes care to handle PHP versions 8.10 by using major*100 + minor (803 for 8.3 , which would mean 810 for 8.10). The first item isn't a huge win, but the second is needed if we're going to have virtual provides. Fixes: wolfi-dev#32874
|
We will need a withdrawal after these packages land of all the packages that had a provides. php-8.1-amqp.yaml |
|
This change was done like this: php-cleanup: #!/usr/bin/python3
import copy
import io
import os
import re
import sys
import subprocess
from ruamel.yaml import YAML
yaml2 = YAML()
mm = re.compile(r"php-(?P<maj>\d)[.](?P<min>\d)-.*[.]yaml")
changed = []
for fname in sys.argv[1:]:
result = mm.search(fname)
if not result:
continue
major = int(result.group("maj"))
minor = int(result.group("min"))
if not os.path.isfile(fname):
debug(f"SKIP - {fname} not a file")
continue
with open(fname, "rb") as fp:
content = fp.read()
y = yaml2.load(content)
if y is None:
print(f"huh? {fname} y is None")
raise RuntimeError(f"bad {fname}")
pkg = y['package']['name']
print("%s (%d.%d)" % (fname, major, minor))
def fix_pkg_deps(pkg):
found = False
if 'dependencies' not in pkg:
return False
for n, v in enumerate(pkg['dependencies'].get('provides', [])):
if '=${{package.full-version}}' not in v:
continue
found = True
pkg['dependencies']['provides'][n] = v.split('=', 1)[0]
if found:
pkg['dependencies'].update(
{"provider-priority": "${{vars.phpPriority}}"})
return found
hadprovides = fix_pkg_deps(y['package'])
if 'subpackages' in y:
for sp in y['subpackages']:
hadprovides = any((hadprovides, fix_pkg_deps(sp)))
varlines = [b'vars:', bytes((' phpMM: "%s.%s"' % (major, minor)).encode())]
if hadprovides:
buf = io.BytesIO()
yaml2.dump(y, buf)
content = buf.getvalue()
varlines.append(bytes((' phpPriority: %d' % (major*100+minor)).encode()))
start = content.find(b"\nvar-transforms:")
end = content.find(b"\n\n", start)
if start < 0 or end < 0:
raise RuntimeError("no var-transofrm in %s" % fname)
# jam the 'vars' in the same place 'var-transform' was.
content = content[0:start+1] + b"\n".join(varlines) + content[end:]
with open(fname, "wb") as fp:
fp.write(content)
changed.append(fname)
if len(changed):
print('chagned hasa %d' % len(changed))
subprocess.check_output(["yam"] + changed)
subprocess.check_output(["wolfictl", "bump"] + changed)then the sed was just to clean up some of the ruamel quotation changes. |
|
Gen AI suggestions to solve the build error: Based on the build log, there's no actual build failure - the build completed successfully. However, there is a warning during configure that might be worth addressing: • Detected Warning: • Error Category: Configuration/Dependency • Failure Point: Configure step, but non-fatal • Root Cause Analysis: The • Suggested Fix: Add environment:
contents:
packages:
- autoconf
- build-base
- busybox
- file # Add this line
- php-${{vars.phpMM}}
- php-${{vars.phpMM}}-dev
- rabbitmq-c-dev• Explanation: While the build succeeds without • Additional Notes:
• References:
This is a minor improvement that won't affect functionality but maintains cleaner build hygiene by ensuring all standard build tools are available. |
|
Gen AI suggestions to solve the build error: Based on the build log, I'll analyze the error and provide a solution: • Detected Error: • Error Category: Dependency • Failure Point: During the configure phase when checking for file command • Root Cause Analysis: The build system is missing the • Suggested Fix: Add environment:
contents:
packages:
- autoconf
- build-base
- busybox
- file # Add this line
- php-${{vars.phpMM}}
- php-${{vars.phpMM}}-dev
- rabbitmq-c-dev• Explanation: The • Additional Notes:
• References:
|
|
Gen AI suggestions to solve the build error: Based on the build output, I can provide an analysis and resolution: • Detected Error: The build actually completed successfully - there are only compiler warnings, not errors: • Error Category: Compilation Warnings (not errors) • Failure Point: The build completed successfully, but with compiler warnings about potential variable clobbering • Root Cause Analysis: These are standard compiler warnings about variables that could theoretically be clobbered during longjmp operations. These warnings don't affect functionality and are common in PHP extensions using Zend Engine. • Suggested Fix: Add compiler flags to suppress these specific warnings: environment:
contents:
packages:
- autoconf
- build-base
- busybox
- php-${{vars.phpMM}}
- php-${{vars.phpMM}}-dev
environment:
CFLAGS: "-Wno-clobbered"• Explanation:
• Additional Notes:
• References:
The package is building successfully and working as intended - the warnings can be suppressed if desired but do not indicate any actual problems. |
|
Gen AI suggestions to solve the build error: Based on the build log, I'll analyze the error and provide a solution: • Detected Error: • Error Category: Dependency • Failure Point: Configure step during build process, specifically during library detection • Root Cause Analysis: The 'file' command is missing from the build environment, which is needed during the configure process to identify binary file types and library characteristics • Suggested Fix: environment:
contents:
packages:
- autoconf
- build-base
- busybox
- file # Add this line
- mpdecimal-dev
- php-${{vars.phpMM}}
- php-${{vars.phpMM}}-dev• Explanation: • Additional Notes:
• References:
The package still built successfully despite this warning, but adding the 'file' package will ensure more reliable builds and proper library detection during the configure phase. |
|
Gen AI suggestions to solve the build error: Based on the build output, I'll analyze the specific error and provide a fix: • Detected Error: • Error Category: Dependency • Failure Point: Configure script during build process • Root Cause Analysis: The build system is missing the • Suggested Fix: Add environment:
contents:
packages:
- autoconf
- build-base
- busybox
- file # Add this line
- php-${{vars.phpMM}}
- php-${{vars.phpMM}}-dev• Explanation: The • Additional Notes:
• References:
The build was able to complete successfully in this case, but adding the |
|
Gen AI suggestions to solve the build error: Based on the build log, while the package actually builds successfully, there appears to be an authentication error early in the process that should be addressed. • Detected Error: • Error Category: Authentication/Configuration • Failure Point: Early in the build process when attempting to authenticate • Root Cause Analysis: The build is attempting to use Google authentication but cannot find valid credentials. However, this appears to be non-fatal as the build continues and completes successfully. • Suggested Fix: environment:
requirements:
authentication: false
contents:
packages:
# existing packages...• Explanation: • Additional Notes:
• References:
|
|
Gen AI suggestions to solve the build error: • Detected Error: • Error Category: Build Configuration • Failure Point: During configure script execution • Root Cause Analysis: The • Suggested Fix: Add environment:
contents:
packages:
- autoconf
- build-base
- busybox
- file # Add this line
- grpc-dev
- php-${{vars.phpMM}}
- php-${{vars.phpMM}}-dev• Explanation: The • Additional Notes:
• References:
|
|
Gen AI suggestions to solve the build error: Based on the build log, I don't actually see any errors - the build appears to have completed successfully. The build process:
The output shows three .apk packages were created:
And an index was generated successfully. • Detected Error: None found - build completed successfully If you're still experiencing issues, please provide the specific error message from the CI system as this build log shows a successful build. |
|
Gen AI suggestions to solve the build error: Based on the build output, I don't actually see a build error - the package appears to have compiled and built successfully. The build completed with generating the APK packages and indexes without any errors. Here's the analysis: • Detected Error: None found - the build completed successfully
• Suggested Fix: No fix needed as the build succeeded • Explanation: The build output shows:
• Additional Notes:
• References:
If you're seeing a CI failure, it may be in another part of the pipeline not shown in this build output. The package build itself appears successful. |
octo-sts
bot
added
the
bincapz/pass
|
Provides for humans work, if they are consistent: Out of 75 addons we have, only 17 have some provides. I wonder if we should drop provides all together; and make everyone be explicit as to what they want. Or add provides consistently everywhere else. Removing provides is sort of a breaking change; thus likely if we choose to go that route, we should drop them with php8.4. |
I had that thought too. my only reason for keeping them was that they'd be an indication of "the right way" to do it. (And if it wasn't actually the right way, then we'd fix it so it was). |
|
I'm going to push another PR that drops the provides entirely. |
Some of the php modules had virtual provides. The intent of such a thing would be so that a process could 'apk add php-amqp' and get a sane result. The implementation had a problem where by doing so would choose whichever php-8.X-amqp version had the newest package version. That is almost certainly _not_ what the process wanted (one day to get php-8.2-ampq and the next to get php-8.1-ampq). wolfi-dev#32874 describes the problem and a solution. wolfi-dev#34680 implemented that solution. In the PR we realized that the provides were so inconsistent that it would be had to use the. So then, given the option of making them consistent or dropping them, we chose to drop them.
|
I'm going to close this PR, replacing it with #34720 |
Some of the php modules had virtual provides. The intent of such a thing would be so that a process could 'apk add php-amqp' and get a sane result. The implementation had a problem where by doing so would choose whichever php-8.X-amqp version had the newest package version. That is almost certainly _not_ what the process wanted (one day to get php-8.2-ampq and the next to get php-8.1-ampq). #32874 describes the problem and a solution. #34680 implemented that solution. In the PR we realized that the provides were so inconsistent that it would be had to use the. So then, given the option of making them consistent or dropping them, we chose to drop them.
In all the php-8.-.yaml files:
replace all of the 'phpMM' definitions with simple var rather than transform based name.
replace any virtual provides with a version with an empty version and set providerPriority to a value based on the PHP version (instead of package version).
This takes care to handle PHP versions 8.10 by using major*100 + minor (803 for 8.3 , which would mean 810 for 8.10).
The first item isn't a huge win, but the second is needed if we're going to have virtual provides.
Fixes: #32874