From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7057983073222131712 X-Received: by 2002:adf:e810:0:b0:1e5:d4ea:d966 with SMTP id o16-20020adfe810000000b001e5d4ead966mr2452006wrm.358.1645020530601; Wed, 16 Feb 2022 06:08:50 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:600c:1d84:b0:37c:dec7:dbbf with SMTP id p4-20020a05600c1d8400b0037cdec7dbbfls2992544wms.3.canary-gmail; Wed, 16 Feb 2022 06:08:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJzNtTTL+Ii+Yg3pTkTpc4Ud5sK2DeH0c4qVmLgUExlQJV+u1wqNUNktB/FgWoa9to8BYlCC X-Received: by 2002:a05:600c:2d02:b0:37b:c7a1:909c with SMTP id x2-20020a05600c2d0200b0037bc7a1909cmr1846706wmf.47.1645020529755; Wed, 16 Feb 2022 06:08:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645020529; cv=none; d=google.com; s=arc-20160816; b=WNNAw2VnM8dMVbIX7w08JTMZ0yTJVD8wDBdmf5XFtxnMaCER8KkoZqHpPNPCnewvTp 9ckvDQyLIG2PLA1ULyY+/pyxBTgEH+x4ZrWsl0a/262wBKTpFHCTMsxbIHwkvVkJehGO qYEteU+domlwIN+sofzka0L6+cUo2sRN/I8hUVhQGhfhBA2CDgsX5Uwq5UJrje+c/OFl qlCmLikCZq8hnsn3wilqd99HMMP5f7lMguC7y0jufpUsfYX6ikMZxYEuQrwVCRFj/CSX YUER0baj/rfcOjbznyc0eX0QBdzedvZY+lT3MZ1mvNB3GKMsBEF27A3RBKYvBzhZRcQy x9tQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id; bh=eNAvshFRaOiJjTdjQchSWEhrQ0MW+Ls9xH0JyV2gQIY=; b=Cb4myGVAopvJzy/ZwPspSV9AHgPhBj37fCks0dIOLnFqUYp3l4OCKB8WlEpXsWmJ8h 9rLpLneErnzpJlGu+Z66Zgk2V/oKk8eyO0b27pQuTBBCFjifxbXcwuyoGwc0S9vb+czB Df7u2LKERUyL1t8AqygPZT1UEbr4U7MuzooU54Xfgf9U8sqCRXuuQiGZl05No3ieALNo HCHQXOTrvxNf5iyVHSTICMqvp1rNmBXEJgvHfJRKIiLwFbhBQ5bZeObXHZjszSQDHJsy qTwhhgOsTwrqFzuJ9JZwx4XBeZ6udQmrwIMjiOl7h69vQGrkFSCTXehp7Opa5z05oPai gz9Q== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of amikan@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=amikan@ilbers.de Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id d14si1856187wrz.4.2022.02.16.06.08.49 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 16 Feb 2022 06:08:49 -0800 (PST) Received-SPF: pass (google.com: domain of amikan@ilbers.de designates 85.214.156.166 as permitted sender) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of amikan@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=amikan@ilbers.de Received: from [127.0.0.1] (host-80-81-17-52.static.customer.m-online.net [80.81.17.52]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPSA id 21GE8laM024993 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 16 Feb 2022 15:08:48 +0100 Message-ID: Date: Wed, 16 Feb 2022 17:08:47 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCHv3 0/3] sstate bug fix Content-Language: en-US To: "Schmidt, Adriaan" , "Schild, Henning" , "isar-users@googlegroups.com" Cc: "jan.kiszka@siemens.com" , "quirin.gylstorff@siemens.com" References: <20220204164124.10396-1-henning.schild@siemens.com> From: Anton Mikanovich In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: i73OtjZPJ9PL 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?