Re: [PATCHv3 0/3] sstate bug fix

[Anton Mikanovich <amikan@ilbers.de>]

15.02.2022 13:08, Schmidt, Adriaan wrote:
> The root problem here is that the sstate code does not "see" when/which files are put into DEPLOY_DIR_IMAGE as a side-effect of tasks.
>
> Unfortunately, we just found out that this problem is not limited to rootfs recipes. There are examples of dpkg recipes [1] placing artifacts into the deploy dir, which also breaks with sstate caching.
>
> One option I can see is:
>    * "forbid" (by convention/documentation) recipes from manually placing files in DEPLOY_DIR_IMAGE
>    * instead, recipes need to set a variable (e.g., FILES_TO_DEPLOY)
>    * these files will be deployed by isar classes
>    * sstate will cache and restore these files
>
> Or we go the OE way:
>    * no-one writes directly to DEPLOY_DIR_IMAGE, but instead to IMGDEPLOYDIR, which is below WORKDIR
>    * isar classes transfer the deployed artifacts to DEPLOY_DIR_IMAGE (in OE this transfer is actually done implicitly by sstate code)
>
> Q:
>    * is DEPLOY_DIR_IMAGE the only location with that problem? Or should we assume that recipes have side-effects writing to arbitrary locations?
>
> Adriaan
>
> [1] https://gitlab.com/cip-project/cip-core/isar-cip-core/-/blob/master/recipes-bsp/efibootguard/efibootguard_0.9-git%2Bisar.bb#L42

The way binaries installed to DEPLOY_DIR_IMAGE definitely need to be 
changed, but does anything speak against merging this patchset?