[yocto] Using smart within an SDK

[Randy Witt]

On 05/26/2015 03:38 PM, Ash Charles wrote:
> On Tue, May 26, 2015 at 3:18 PM, Randy Witt
> <randy.e.witt at linux.intel.com> wrote:
>> Did you source the environment-setup script? If so, what distro were you
>> using?
> Ubuntu 15.04 (Vivid-Vervet).  I used an SDK created based on the
> gumstix-console-image rather than a mainstream image from meta-yocto
> so perhaps there is a particular configuration etc. that messes up the
> creation of the SDK?
> <snip>
>> 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.
> Okay---If I understand correctly, that's a little more limiting than I
> would like.  No matter how many different SDKs I provide, each
> customer will need a different set of a software packages in their
> sysroot.  Yocto makes it easy to build up a big sstate or package
> repository and post this online---users can just grab a baseline SDK
> and then pull in the pieces they need (which probably is pretty
> comfortable for folks who are used to a 'sudo apt-get install
> libboost-dev' etc.).
>
> Based on this, should I be turning my attention back to using smart
> install with a regular SDK environment or is this imagined workflow
> just not a reasonable objective?

It is a bit of a different workflow than we were initially looking at, but I 
don't see a reason we couldn't do it. The locked signatures file should be able 
to be a superset of items you would want, so theoretically if you only wanted 
items from your sstate mirror to be used, the manifest would contain all items 
on the mirror. This would prevent the user from building something locally 
rather than pulling from the mirror and potentially not matching.

The nativesdk items are not in the extensible sdk, and the native items are just 
part of the bitbake workspace. This is why it should be fairly easy to add what 
you want. Because in the end it would just be adding an sstate mirror and doing 
a bitbake "native-foo". And we could wrap that with devtool or some other command.

I do see the convenience and why you want it, so I'll talk it over with Paul 
tomorrow.

> Thanks,
> --Ash
>