[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