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

Alex J Lennon ajlennon at dynamicdevices.co.uk
Mon Apr 21 23:50:20 PDT 2014


On 22/04/2014 02:36, Mark Hatle wrote:
> 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.
>

Is there a reason for this? Surely having a package index that is out of
sync with the packages until a manual operation is performed isn't ideal?

>> 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
>

Thanks, that's useful

However I still believe the core question stands, which is why the
package index is out of sync, and why it's a good thing to have to run
bitbake package-index manually to bring the package index back into sync
with the packages?

I too export the feed directories to a server for 3rd party consumption
via compressed rsync over SSH. I don't want to expose more on the server
than a simple SSH endpoint, and rsync seems a sensible way to minimise
copying times, so either I need the package index to be correct prior to
the rsync, I need to export, say, an NFS filesystem which I don't want
to do, or I need some createrepo specifics on what I would prefer to be
a dumb web-server.
 
Best,

Alex

> --Mark
>
>> Thanks,
>>
>> Alex
>>
>>
>>
>

-- 

Dynamic Devices Ltd <http://www.dynamicdevices.co.uk/>

Alex J Lennon / Director
1 Queensway, Liverpool L22 4RA

mobile: +44 (0)7956 668178

Linkedin <http://www.linkedin.com/in/alexjlennon> Skype
<skype:alexjlennon?add>

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended
recipient(s). Any unauthorized disclosure, dissemination, distribution,
copying or the taking of any action in reliance on the information
herein is prohibited. E-mails are not secure and cannot be guaranteed to
be error free as they can be intercepted, amended, or contain viruses.
Anyone who communicates with us by e-mail is deemed to have accepted
these risks. Company Name is not responsible for errors or omissions in
this message and denies any responsibility for any damage arising from
the use of e-mail. Any opinion and other statement contained in this
message and any attachment are solely those of the author and do not
necessarily represent those of the company.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20140422/e4aeb176/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ddlogo-4.png
Type: image/png
Size: 3997 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20140422/e4aeb176/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linkedin.png
Type: image/png
Size: 631 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20140422/e4aeb176/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: skype.png
Type: image/png
Size: 800 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20140422/e4aeb176/attachment-0002.png>


More information about the yocto mailing list