Re: [PATCH 1/1] dpkg-runbuild: start with clean apt-cache

[Jan Kiszka <jan.kiszka@siemens.com>]

On 05.02.24 08:35, Moessbauer, Felix (T CED OES-DE) wrote:
> On Sun, 2024-02-04 at 12:10 +0100, Jan Kiszka wrote:
>> On 29.01.24 11:50, Uladzimir Bely wrote:
>>> On Wed, 2024-01-24 at 09:30 +0100, 'Felix Moessbauer' via isar-
>>> users
>>> wrote:
>>>> The global apt-cache is imported during dpkg-runbuild and cleaned
>>>> once
>>>> the function completes. This works properly on successfull
>>>> builds.
>>>> However, in case of a build failure, the apt-cache dir is not
>>>> cleaned
>>>> and re-read on the next build, leading to unstable builds in case
>>>> erronous data was added to the cache.
>>>>
>>>> This patch adds the local apt-cache dir to the cleandirs and by
>>>> that
>>>> cleans it before the function is executed.
>>>>
>>>> Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
>>>> ---
>>>>  meta/classes/dpkg.bbclass | 1 +
>>>>  1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/meta/classes/dpkg.bbclass
>>>> b/meta/classes/dpkg.bbclass
>>>> index 3057329f..8800ce41 100644
>>>> --- a/meta/classes/dpkg.bbclass
>>>> +++ b/meta/classes/dpkg.bbclass
>>>> @@ -34,6 +34,7 @@ CP_FLAGS ?= "-Ln --no-preserve=owner"
>>>>  CP_FLAGS:sid ?= "-L --update=none --no-preserve=owner"
>>>>  
>>>>  # Build package from sources using build script
>>>> +dpkg_runbuild[cleandirs] += "${WORKDIR}/rootfs"
>>>>  dpkg_runbuild[vardepsexclude] +=
>>>> "${SBUILD_PASSTHROUGH_ADDITIONS}"
>>>>  dpkg_runbuild() {
>>>>      E="${@ isar_export_proxies(d)}"
>>>> -- 
>>>> 2.39.2
>>>>
>>> Applied to next, thanks.
>>>
>>
>> This does not work that cleanly as it suggests: rootfs requires sudo
>> rights to be cleaned reliably. I'm now getting build failures on
> 
> Despite the name, this is NOT a rootfs but just a regular directory
> with only the apt cache in it. All artifacts inside this cache should
> be writable by non root.
> 
>> rebuilds due to that. Maybe using the root_cleandirs flag instead
>> would
>> work?
> 
> Another undocumented feature... But yes, the code looks like this would
> solve the issue.

Will you have a look? I'd like to not have this regression in the
upcoming release.

Jan

-- 
Siemens AG, Technology
Linux Expert Center