[OE-core] BB_SRCREV_POLICY doesn't seem to work

[Martin Jansa]

On Thu, Jan 31, 2013 at 07:19:20AM -0500, Robert P. J. Day wrote:
> On Thu, 31 Jan 2013, Eric Bénard wrote:
> 
> > Hi Robert,
> >
> > Le Thu, 31 Jan 2013 05:37:59 -0500 (EST),
> > "Robert P. J. Day" <rpjday at crashcourse.ca> a écrit :
> > >   ok, what have i done wrong?  i thought the whole point of
> > > BB_SRCREV_POLICY was to make the above possible.
> > >
> > no idea if that the solution but did you do a cleansstate and removed
> > the initaly downloaded sources to fetch again the sources ?
> 
>   i did not ... that's necessary?  that's kind of important to know.
> let me describe the situation i have to see if BB_SRCREV_POLICY is
> actually going to do me any good.
> 
>   here's my global site.conf file:
> 
> SCONF_VERSION = "1"
> SOURCE_MIRROR_URL ?= "file:///home/rpjday/oe/dist/tarballs/"
> INHERIT += "own-mirrors"
> BB_GENERATE_MIRROR_TARBALLS = "1"
> # BB_NO_NETWORK = "1"
> 
> so, as you can see, whenever i end up fetching any new source, it ends
> up as a tarball and i copy it into my long-lived own-mirrors
> "tarballs" directory.  obviously saves me buckets of time.
> 
>   now say i've started a new build and i've done all the fetching
> without involving BB_SRCREV_POLICY.  i suddenly realize i need to move
> to somewhere without network access, so i quickly add
> 
>   BB_SRCREV_POLICY = "1"

BB_SRCREV_POLICY = "cache"

right?

> 
> and do another fetchall to cache all the SRCREV stuff.  it *appears*
> that that does nothing for me since all my fetching had been done.
> 
>   you're saying i need to cleansstate first, then do the fetchall
> *again*?  i might be misunderstanding this but, at this point,
> BB_SRCREV_POLICY is starting to look like more trouble than it's worth
> since it requires planning, *knowing* that you'll be without a network
> later and, worst of all, if you start a fresh build, it does you no
> good since all that cached SRCREV content is in the other build
> directory's tmp directory.
> 
>   given that all of this can be avoided by just avoiding tag names,
> i'm liking that option more and more. :-)
> 
> rday
> 
> -- 
> 
> ========================================================================
> Robert P. J. Day                                 Ottawa, Ontario, CANADA
>                         http://crashcourse.ca
> 
> Twitter:                                       http://twitter.com/rpjday
> LinkedIn:                               http://ca.linkedin.com/in/rpjday
> ========================================================================

> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core


-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20130131/042d6c80/attachment-0002.sig>