RFC: fixing package version QA issue for linux-firmware updates

[pabigot]

When I reworked linux-firmware to use the OE-Core base augmented by overrides taken from the raspbian distro (#245), I changed the version format so that it identified the git version from all three sources:

SRCREV_FORMAT_rpi = "default+raspbian-nf+raspbian-bluez"

This reflects that what we build uses different firmware from raspbian-nf for:

brcmfmac43430-sdio brcmfmac43455-sdio

and adds firmware from raspbian-bluez for:

BCM43430A1.hcd BCM4345C0.hcd

This was useful as it allowed diagnosis of #260 without lots of back and forth. The longer version number also makes more clear that the rpi packages are not entirely the same as ones built for other architectures (which may be good, or bad, depending).

Now we need to advance the raspbian-bluez commit, because there's an updated firmware. The problem is that doing this causes a QA error:

ERROR:
linux-firmware-1_0.0+gitAUTOINC+d114732723+86e88fbf03+ade2bae1aa-r0 do_packagedata_setscene:
QA Issue: Package version for package linux-firmware went backwards which would break package feeds
from (1:0.0+git0+d114732723+86e88fbf03+e28cd7ee86-r0.0
   to 1:0.0+git0+d114732723+86e88fbf03+ade2bae1aa-r0.0) [version-going-backwards]

There are several approaches I can conceive:

• Live with the version-going-backwards. Non-starter for production use.

• Come up with some magic so the AUTOINC part of SRCREVPV doesn't pay attention to the change in the non-default SRCREV contributors (which is the behavior I unconsciously assumed).

• Remove the SRCREV_FORMAT so we match OE-Core and just silently replace the -sdio firmware package contents along with adding the BCM434X ones if the packages are built for _rpi. Might cause some confusion in multi-machine build areas? Or is that already a problem?

• Make a second stab at providing a different package that supersedes linux-firmware only for the pieces that are out of date.

• Convince people (vendors and maintainers) to keep linux-firmware up to date so we don't have to maintain a fork.

I don't like any of those (well, I love the last one, but it's probably impractical).
Something's gotta be done.
Opinions?

[pabigot]

@otavio I notice you've updated meta-raspberrypi linux-firmware. The problem discussed in this issue wasn't encountered because raspbian-nf went to lexically greater SHA1. Nonetheless, if you have insight as to a preferred fix I'd appreciate it.

At this time I'm tending towards option four (separate package for raspberry-pi override firmware). Attempts to get upstream to fix this elicited no response.

[otavio]

A separated recipe makes most since as it is what it really is. Appending it to linux-firmware is wrong conceptually.

[pabigot]

@otavio That's what I figured (deep sigh). OK, I'll work towards that. It'll be two recipes, though, since there are two external sources: probably bluez-firmware and firmware-nonfree-rpi-distro to make provenance more clear. @agherzan @hhromic FYI, please comment if concerned and bring in anybody else who should provide design input.

[otavio]

To provide a good upgrade path in future, it would be good to also create a packagegroup-rpi-base which rdepends on the firmware and other "base" packages, thus providing an upgrade path.

[hhromic]

hi @pabigot , I'm not an expert in the matter, but my humble opinion is aligned with @otavio 's , a separate recipe for each firmware makes more sense and seems easier to maintain

[agherzan]

The PR looks like a good way forward to me too.

[kraj]

To provide a good upgrade path in future, it would be good to also create a packagegroup-rpi-base which rdepends on the firmware and other "base" packages, thus providing an upgrade path.

this will have to be machine specific, since not all rpi variants have same chipsets for which these firmwares are targetted. Secondly, some of them not even have that hardware or peripheral.