[yocto] Unusual RPM / Smart Bug When Changing Architecture

[Darcy Watkins]

Hi,

We encountered some rather unusual anomalies related to RPM / Smart in
both the build system and when applying updates on the target.

1.  We had a series of RPM packages for HW controller specific FW
images.  Let's say they are called something like:
    - fw-image-a
    - fw-image-b
    - fw-image-c
2.  When originally introduced, we erroneously forgot to have the
recipes "inherit allarch" so they were originally built as
'cortexa7hf_vfp_neon' rather than 'all'.
3.  This made it onto the build server, into the RPM feeds, etc. and
even installed onto some target machines.
4.  We spotted this later and changed it to use the 'all' architecture.
This triggered the RPMs to be rebuilt (but this was same firmware just
repackaged).  Since the firmware had not changed, no one noticed that
the generated rootfs was built from the wrong RPMs.
5.  When the radio module FW was updated we noticed that the new
firmware wasn't making it into the generated rootfs images.  Upon
investigation I discovered that the rootfs task was grabbing the old
RPMs from the 'cortexa7hf_vfp_neon' sub-feed even though there was newer
version RPMs under 'all'.  I renamed the RPMs under the
'cortexa7hf_vfp_neon', appending a '.bk1' extension to them, after which
the rootfs task properly grabbed the newer RPMs from the 'all' sub-feed.
6.  Then we tried using Smart on the target to handle the update /
upgrade scenario on the target.  What we observed is that the upgraded
RPM was installed, but the old one (with the different architecture) was
not removed.  Now they were both present, two versions of the same
package, but smart didn't treat them as the same because they had
different arch (one 'all' and the other 'cortexa7hf_vfp_neon'.

This is a system based on 'daisy' branch.

It appears that:
- The rootfs task must iterate through arch sub-feed looking for RPMs
and as soon as it chances upon any sub-feed that has RPMs present for
that package, it doesn't continue through the rest to see if there may
be more (and newer ones) under one of the other sub-feeds.  This
affected the content of the generated manifest database (and what wound
up in the images), and also explains why renaming the files to get them
out of the way worked as a workaround.
- The Smart PM appears to consider the architecture (you can see an
appended '@cortexa7hf_vfp_neon' or '@all' in some of what it outputs),
and must treat it as part of what makes a package distinct (rather than
filtering it out like it would the version info).

I understand that changing the architecture of a package is not a
typical use case in a package.

Now my questions...

Is this a known issue?  Has it been fixed in a newer branch?  If so,
which one?


-- 

Regards,

Darcy

---

Darcy Watkins
Staff Engineer, Firmware
Sierra Wireless
13811 Wireless Way, Richmond, BC
Canada, V6V 3A4
[P1]