/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 Reproducible: Always Steps to Reproduce: 1. file /usr/lib/firmware/a300_pm4.fw.xz 2. file /usr/lib/firmware/a300_pfp.fw.xz 3. Actual Results: Broken symlinks Expected Results: No broken symlinks - a package must appropriately manage symlinks & create them ONLY when the target is present.
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.