One way to keep it allarch would be to package
${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.AP6212.txt
${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.MUR1DX.txt
in 2 separate packages and handle
${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt
symlink with update-alternativesmost MACHINEs won't install either of these packages and those which need it will pull the right one (e.g. through MACHINE_EXTRA_RRECOMMENDS). In worst case someone will try to install both packages and based on u-a priority one of them will win (use higher priority for the more common version). Cheers, On Fri, Aug 24, 2018 at 4:53 AM Andre McCurdy <[email protected]> wrote: > On Thu, Aug 23, 2018 at 1:15 AM, Ryan Harkin <[email protected]> > wrote: > > > > So now the ln issue is resolved, I'm not convinced my MACHINEOVERRIDES is > > the correct approach. Does anyone have any feedback on how I can improve > > that? > > If you want to make a configurable symlink then perhaps the more usual > approach would be to just use a variable in the linux-firmware recipe > to weakly define a default target for the symlink. Machine config > files could then either do nothing (ie use the default) or provide > their own value. For example, in the linux-firmware recipe: > > BCM43430_NVRAM_SYMLINK ?= "brcmfmac43430-sdio.AP6212.txt" > > FILES_${PN}-bcm43430-nvram = " \ > ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt \ > ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.AP6212.txt \ > ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.MUR1DX.txt \ > " > > do_install() { > ... > ln -sf ${BCM43430_NVRAM_SYMLINK} > ${D}${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt > } > > And then in the machine config files of machines which need the MUR1DX > firmware instead of the default, add: > > BCM43430_NVRAM_SYMLINK = "brcmfmac43430-sdio.MUR1DX.txt" > > However... note that currently the linux-firmware recipe is > architecture independent (ie it won't be rebuilt if the target is > changed). Adding a machine specific symlink is going to cause problems > with that, so the above is still not a full solution. >
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
