[oe] [meta-oe][PATCH 0/3] Add bits to save/restore URI headrevs

Christopher Larson chris_larson at mentor.com
Tue Dec 15 20:40:46 UTC 2015


On Tue, Dec 15, 2015 at 12:49 PM, Martin Jansa <martin.jansa at gmail.com>
wrote:

> On Tue, Dec 15, 2015 at 12:37:44PM -0700, Christopher Larson wrote:
> > From: Christopher Larson <chris_larson at mentor.com>
> >
> > This is useful to support BB_NO_NETWORK with AUTOREV, by letting someone
> ship
> > dumped headrevs to the user, who then inherit this class, which ensures
> that
> > the cached headrevs are used, and upstream is not contacted at parse
> time.
> > BB_SRCREV_POLICY will be set to "cache" as well, if it's not already
> set, as
> > otherwise bitbake will contact upstream to update the cached values.
> >
> > This is helpful when shipping downloads to someone when there's a desire
> to
> > support both BB_NO_NETWORK and AUTOREV.
> >
> > The restore_headrevs.bbclass will restore dumped headrevs at config
> parse time
> > (add to INHERIT), and the oe.headrevs python module provides a function
> one
> > can call to dump the headrevs.
>
> Maybe I'm missing something, but what's advantage of shipping something
> with AUTOREV which is then used together with BB_NO_NETWORK?
>

It's quite useful to not have to go through and manually lock down all your
kernels recipes when doing a release. All our releases ship with sources
and are BB_NO_NETWORK-capable, as that's a requirement for a lot of folks.


> We already have some implementation in bitbake which dumps latest
> SRCREVs used by all recipes (including AUTOREV) onces so I would expect
> that the release will ship this .inc files with locked revisions and if
> the user of such release wants to use BB_NO_NETWORK he will also include
> that .inc file with locked revisions.
>
> Is it because it's easier of faster to dump them from the headrefs db
> you already ship with release and you don't want to generate .inc from
> buildhistory?


Actually, this was in my patch queue from before buildhistory existed, and
I somehow managed to forget about buildhistory-collect-srcrevs :) Feel free
to ignore this, in that case.
-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics



More information about the Openembedded-devel mailing list