On Tue, Dec 15, 2015 at 12:49 PM, Martin Jansa <[email protected]> wrote:
> On Tue, Dec 15, 2015 at 12:37:44PM -0700, Christopher Larson wrote: > > From: Christopher Larson <[email protected]> > > > > 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 -- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
