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

[Mike Looijmans <mike.looijmans@topic.nl>]

On 07/10/2013 07:45 PM, Martin Jansa wrote:
> On Wed, Jul 10, 2013 at 06:39:20PM +0100, Paul Eggleton wrote:
>> 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.
>
> I would try to add
> DISTRO_HOST_NAME[vardepvalue] = "${DISTRO_HOST_NAME}"
>
> that way each builder should create own sstate archive.

I forgot to give my final feedback on this, it would be impolite to ask 
for advise and don't report back on whether it was useful, so here goes:

I've been using that setting for a while now and it does exactly what I 
wanted it to do. Every build machine creates its own feed configuration, 
while the big buildserver creates about everything else. The shared 
state cache is a big time saver for us.

Thanks!

Mike.


Met vriendelijke groet / kind regards,

Mike Looijmans


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) – (0)499 - 33.69.79
Telefax: (+31) - (0)499 - 33.69.70
E-mail: mike.looijmans@topic.nl
Website: www.topic.nl

Dit e-mail bericht en de eventueel daarbij behorende bijlagen zijn uitsluitend bestemd voor de geadresseerde, zoals die blijkt uit het e-mail bericht en/of de bijlagen. Er kunnen gegevens met betrekking tot een derde instaan. Indien u als niet-geadresseerde dit bericht en de bijlagen ontvangt, terwijl u niet bevoegd of gemachtigd bent om dit bericht namens de geadresseerde te ontvangen, wordt u verzocht de afzender hierover direct te informeren en het e-mail bericht met de bijlagen te vernietigen. Ieder gebruik van de inhoud van het e-mail bericht, waaronder de daarbij behorende bijlagen, door een ander dan de geadresseerde is onrechtmatig jegens ons dan wel de eventueel in het e-mail bericht of de bijlagen voorkomende andere personen. TOPIC Embedded Systems is niet aansprakelijk voor enigerlei schade voortvloeiend uit het gebruik en/of acceptatie van dit e-mail bericht of de daarbij behorende bijlagen.

The contents of this message, as well as any enclosures, are addressed personally to, and thus solely intended for the addressee. They may contain information regarding a third party. A recipient who is neither the addressee, nor empowered to receive this message on behalf of the addressee, is kindly requested to immediately inform the sender of receipt, and to destroy the message and the enclosures. Any use of the contents of this message and/or the enclosures by any other person than the addressee or person who is empowered to receive this message, is illegal towards the sender and/or the aforementioned third party. TOPIC Embedded Systems is not  liable for any damage as a result of the use and/or acceptance of this message and as well as any enclosures.