Re: sstate-cache and making a package "host-dependent"

[Paul Eggleton <paul.eggleton@linux.intel.com>]

Hi Mike,

On Wednesday 10 July 2013 15:05:23 Mike Looijmans wrote:
> I added a buildserver that also exports its "sstate-cache" directory, so
> that other build machines can grab their stuff from it. This works fine,
> but I have one problem. Some packages are meant to be dependent on the
> system that built it. I want to enforce that each build machine creates
> its own package, and does not grab it from the sstate-cache of the
> central server.
> 
> For example,
> 
> $ cat recipes-core/meta/distro-feed-configs.bbappend
> PRINC="1"
> DISTRO_HOST_NAME ?= "${@os.uname()[1]}"
> DISTRO_FEED_NAME ?= "feed"
> DISTRO_FEED_PREFIX = "topic"
> DISTRO_FEED_URI =
> "http://${DISTRO_HOST_NAME}/${DISTRO_FEED_NAME}/${MACHINE}"
> 
> 
> The purpose being that the host name of the machien that built the image
> ends up in the opkg config files. This works just fine.
> Now that we have a central server, all images on all build hosts grab
> the package from the sstate-cache server, resulting in the feed pointing
> to the central server instead of the private one, which is not what I
> wanted to happen.
> 
> After reading the documentation, I added the following line to the recipe:
> 
> PACKAGE_ARCHS[vardeps] = "DISTRO_FEED_URI"
> 
> This did not have the desired effect. The package is still retrieved
> from the cache, and not rebuilt locally. Even if I clean and force a
> rebuild of the distro-feed-configs package, the package that ends up in
> the image is still the one from the central server.
> 
> What am I missing here?

I think distro-feed-configs (from meta-oe, not OE-Core) is for package 
installation on the target, and has nothing to do with shared state.

I'm not sure if it's entirely appropriate, but you could take a similar 
approach to the one we use for preventing native sstate packages from mixing 
across different distributions (mostly to sidestep host glibc version 
dependency problems) - set SSTATE_EXTRAPATH to some value for the recipes you 
don't want to share and then the packages will go into a subdirectory named 
with that value; you could then delete these automatically from the server.

Cheers,
Paul

PS if you could please avoid replying to an existing thread for a new 
discussion, that would be great.

-- 

Paul Eggleton
Intel Open Source Technology Centre