On 05/22/2015 03:24 PM, Ash Charles wrote:
On Mon, May 18, 2015 at 10:13 PM, <randy.e.w...@linux.intel.com> wrote:
The idea is that an sdk will comprise of a manifest(contains list of
sstate items in the sdk) and some location that contains the items in the
manifest. So to update the sdk you would run a command and give it the
location of the manifest and sstate, and it would make your sdk match what
is in the manifest.
So the sstate could be hosted on a webserver, nfs, locally, etc.
Thanks Randy.
I stepped through the process of making an extensible SDK based on my
image. Is the conf/locked-sigs.inc file the manifest you mentioned?
Yes, that is the one.
Unfortunately, devtool is failing for me ("ImportError: No module
named site"...looks like the SDK is missing a python library?) but it
is great to at least be able to build it and get a sense of the
contents.
Did you source the environment-setup script? If so, what distro were you using?
I'm uploading my sstate to a server so theoretically updating would be
a process of grabbing items from this server cache into the
'sstate-cache' directory within the SDK? If I needed a new package
not originally included in the SDK, I would do something like devtool
get opencv-dev?
We were thinking it wouldn't be so granular Basically it would end up matching
everything in a manifest rather than asking for one particular package. So it
would look more like "devtool publish-sdk location", followed by users being
able to then update to whatever "sdk's" exist at that location.
Thanks for any insights. I realize this is work-in-progress so I'm
just looking to get a sense of how things might work.
--Ash
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
