Broken symlink on latest commit
graysky2 opened this issue · 5 comments
/firmware-nonfree/debian/config/brcm80211/brcm/brcmfmac43455-sdio.bin
is a broken symlink
% stat brcmfmac43455-sdio.bin
File: brcmfmac43455-sdio.bin -> ../cypress/cyfmac43455-sdio.bin
Size: 31 Blocks: 0 IO Block: 4096 symbolic link
Device: 0,39 Inode: 237316 Links: 1
Access: (0777/lrwxrwxrwx) Uid: ( 1000/ facade) Gid: ( 100/ users)
Access: 2022-06-13 13:36:13.412687941 -0400
Modify: 2022-06-13 13:36:13.392687643 -0400
Change: 2022-06-13 13:36:13.392687643 -0400
Birth: 2022-06-13 13:36:13.392687643 -0400
Yet in /firmware-nonfree/debian/config/brcm80211/cypress/
there is no such file:
cyfmac43430-sdio.bin cyfmac43455-sdio.clm_blob cyfmac43455-sdio-standard.bin
cyfmac43430-sdio.clm_blob cyfmac43455-sdio-minimal.bin README.txt```
cyfmac43455-sdio.bin
gets created in postinst and points to cyfmac43455-sdio-standard.bin
by default.
https://github.com/RPi-Distro/firmware-nonfree/blob/bullseye/debian/firmware-brcm80211.postinst#L7
The idea being that it allows the user can switch between cyfmac43455-sdio-standard.bin
and cyfmac43455-sdio-minimal.bin
. https://github.com/RPi-Distro/firmware-nonfree/blob/bullseye/debian/config/brcm80211/cypress/README.txt
Is there a reason why the symbolic link can't point to cyfmac43455-sdio-standard.bin
by default? Come to think of it, given that the cyfmac43455-sdio*
firmware is always loaded via a symbolic link in the brcm
directory, is there any reason not to keep the original filename as it was, i.e. cyfmac43455-sdio.bin
?
Is there a reason why the symbolic link can't point to
cyfmac43455-sdio-standard.bin
by default?
That would break the ability to switch between them. I could probably add it and tell the packaging system not to install it.
Come to think of it, given that the
cyfmac43455-sdio*
firmware is always loaded via a symbolic link in thebrcm
directory, is there any reason not to keep the original filename as it was, i.e.cyfmac43455-sdio.bin
?
We could revert to the old filename and remove the brcmfmac43455-sdio.bin
symlink, which would then be created in postinst.
It would be a headache in either case, since that's making a large change to a package that had already shipped, needing some additional logic to handle upgrades so that the symlink points to the right place regardless of the starting point.
If we're going to be the source of these files, in the ideal world, I think we should have a separate repo structured in a way that makes sense for third party distros. Using debian packaging for this just isn't working.
That would break the ability to switch between them. I could probably add it and tell the packaging system not to install it.
@XECDesign That would be the best in my opinion. Having this dangling symlink broke non-debian integrations.
In debian, firmware-nonfree is enough of a mess that I'd rather not also worry about other distros here.
If anybody wants to set up another repo just for a friendlier distribution of these files, I think that's the way to go.