[yocto] Question about rebuilding RPM package index for updated RPMs when bitbake completes

Mark Hatle mark.hatle at windriver.com
Mon Apr 21 18:36:28 PDT 2014


On 4/20/14, 7:15 AM, Alex J Lennon wrote:
> Hi,
>
> I'm trying to put in place a development workflow using the PR server,
> RPM package feeds and smart update/install on a target.
>
> I see that when I modify and rebuild my recipe, foo, the PR server
> increments its count within the RPM filename, but the RPM feed data
> doesn't seem to update.
>

...

> So if I am understanding the above correctly, when I make a change to a
> recipe and build it, PR automatically
> updates, the old RPM is removed and the new RPM added to the feed
> directory. However the package index
> for the feed is not updated.
>
> So if at that point I try to make use of the feed on a target I am
> likely to find something is broken.

The feed is normally indexed (createrepo) either when you manually run the 
package-index operation, or when you construct a filesystem.  Until you do that, 
the feed directories are transient.

> If that is true would it make sense to leave the old RPM in the feed
> directory until package-index
> is re-ran, or to run package-index automatically at the end of a build
> when RPMs have changed?

I -never- export the feed directories from the project directory.  Instead, I 
copy the packages from the feed directory to where I share them, and then run 
the indexer against the external repository.  This preserves the older versions 
and also makes the new ones available.

To run the indexer I have to configure and run it manually...

PATH=/home/mhatle/build-6.0-RCPL-test/build/tmp/sysroots/x86_64-linux/bin:/home/mhatle/build-6.0-RCPL-test/bitbake/tmp/sysroots/x86_64-linux/usr/bin:$PATH
/home/mhatle/build-6.0-RCPL-test/bitbake/tmp/sysroots/x86_64-linux/usr/bin/createrepo 
--update -q <path to feed>

So for qemux86_64, I end up running the above three times.  all, x86_64 and 
qemux86_64.

Then on the target I just do:

smart update
smart upgrade -y

--Mark

> Thanks,
>
> Alex
>
>
>




More information about the yocto mailing list