On Mon, 2015-07-20 at 10:08 -0600, Gary Thomas wrote:
> On 2015-07-20 09:39, Burton, Ross wrote:
> >
> > On 20 July 2015 at 16:28, Gary Thomas <[email protected] 
> > <mailto:[email protected]>> wrote:
> >
> >        NOTE: Stamp 
> > /home/local/rpi2_2015-03-05/tmp/stamps/i686-linux/dbus-native/1.8.16-r0 is 
> > not reachable, removing related manifests
> >            ... many more
> >
> >     What do these mean and should I be worried about seeing them?
> >
> >
> > That basically means that e.g. the dbus-native in the layers is newer than 
> > the version in the sysroot, so it is now removing dbus-native 1.8.16 from 
> > the sysroot so it can later
> > install 1.8.<something newer>.  Now this code has pretty much proven itself 
> > we can probably remove those messages.
> >
> > Previously it just wrote over the top and hoped for the best, with logic to 
> > error out if one native recipe wrote over another recipe's files.  This was 
> > good for determinism but bad
> > for moving files between recipes or renaming recipes (which was impossible).
> 
> Thanks for the explanation.  I can see that the code for this
> is fairly new (early June) and I must have not seen many of these
> so it grabbed my attention.  The build tree in question was last
> touched in March, so there obviously were many cases of this
> situation.
> 
> Related query: I tend to build & rebuild in the same tree (typically
> only one platform per build tree) over long periods of time (like my
> RaspberryPi2 tree which I've had around for many months).  Over time,
> there may be a lot of updated builds and I end up with many "duplicated"
> trees in my tmp/work (I don't use rm_work), e.g.
>    tmp/work/x86_64-linux/libfontenc-native/1_1.1.3-r0
>    tmp/work/x86_64-linux/libfontenc-native/1_1.1.2-r0
>    tmp/work/x86_64-linux/glib-2.0-native/1_2.44.1-r0
>    tmp/work/x86_64-linux/glib-2.0-native/1_2.44.0-r0
> 
> Is there a [simple] way to remove just the old/redundant trees?

The code you're talking about above now does this (without rm_work)!

Cheers,

Richard



-- 
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto

Reply via email to