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
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
