Bug 2231712
| Summary: | /usr/lib/firmware/a300_pm4.fw.xz: broken symbolic link to qcom/a300_pm4.fw.xz and /usr/lib/firmware/a300_pfp.fw.xz: broken symbolic link to qcom/a300_pfp.fw.xz | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | John Dodson <jwadodson> |
| Component: | linux-firmware | Assignee: | David Woodhouse <dwmw2> |
| Status: | NEW --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 38 | CC: | dwmw2, jforbes, jwboyer, kernel-maint, laura, pbrobinson |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
John Dodson
2023-08-13 14:11:34 UTC
What version of firmware? linux-firmware-20230804-153.fc38.noarch (I assume - as that's the owner of the links) Where the links should be owned by the package that provides the target. 2023-08-13T01:00:55+1000 SUBDEBUG Upgrade: linux-firmware-20230804-153.fc38.noarch > Where the links should be owned by the package that provides the target.
Yup, they were moved to the qcom-firmware sub package, but moving just the links is a lot of PITA logic for 2 links that basically don't cause an issue if you don't have the HW, and without the rest of the firmware for QCom HW you'll have other problems so it's unlikely I'll fix this until upstream drops the symlinks once the relevant affected kernels that may need this go EOL.
"don't cause an issue" ??? Really? Broken "system" symlinks are a very big issue for me. This has been an issue previously eg. Lenovo links in the case of firmware. They were fixed. How do we "teach" the people creating such links to manage them appropriately? Especially in "firmware" packages that could be subverted by a broken link? They should not be allowed to be moved to another (sub?) package unless appropriately managed. Regardless of the "work/logic" involved. It's good practice. > Broken "system" symlinks are a very big issue for me. But what is the "very big issue" that it causes from a technical PoV? > This has been an issue previously eg. Lenovo links in the case of firmware. Yes, because I took the time to fix it, I don't have that much time, I will eventually look into it but it's not currently high priority for me. |