[OE-core] [PATCH] rpm: Avoid leaking temporary scriplet files

[Alexander Kanavin]

The temporary files are written here (macros.in file):

%_tmppath               %{_var}/tmp

What I don't understand is why they end up in the host /var and not
the rootfs one. The rpm database location is deduced from to _var as
well, and it does get created in the correct location. Further
investigation needed...

Alex

2018-06-25 21:20 GMT+02:00 Alexander Kanavin <alex.kanavin at gmail.com>:
> 2018-06-25 18:47 GMT+02:00 Mark Hatle <mark.hatle at windriver.com>:
>> My question is "why is this a problem"?  (Why is debugging on for normal usage?)
>>
>> If you want to enable debugging with RPM, leaving the files is the right answer.
>>  Otherwise, as mentioned in the post it's REALLY hard to debug scriptlet failures.
>
> Not at all. I've done quite a bit of scriptlet failure debugging (in
> preparation for turning their failures into actual bitbake failures),
> and haven't had to look at stuff in /var/tmp once. I'm fine with
> deleting them.
>
> When debugging is enabled, rpm writes each line of the scriptles as it
> is being executed into the log, so you don't generally need to look at
> the whole scriptlet. And even if you do, it's written as plaintext
> into the beginning of the rpm file, so just look at it with 'less'.
>
>> As for the rootfs.py cleaning them up, it's simply not possible -- assuming they
>> end up in a shared tmp dir, as you wouldn't have any idea who created them..
>> this build, or another, or a system process....  (Now if they only install into
>> the image's /var/tmp, thats a completely different case -- but I still question
>> why debug is enabled at all.)
>
> Then we should write them to the rootfs /var/tmp and not the one on
> the host. Or even ${T} where the rest of rpm/dnf logs go. Then they
> don't need to be cleaned at all.
>
>> This suggests some (probably[*]) larger, upstreamable work done
>> in rpm itself, to be able to configure that behavior. I think
>> this is better than nothing, for now. Perhaps the bug report
>> shouldn't be closed, and this be merged as a workaround? (It
>> causes real issues, at least for images with lots of
>> pre/postinstalls.)
>
> Sorry but no. I do not want 'workarounds' as merging them removes all
> incentive for you to develop a proper fix.
>
>> Does anybody see value in what --rpmverbosity=debug brings, as
>> opposed to the default level of info? Would dropping that from
>> lib/oe/package_manager.py's RpmPM._invoke_dnf be a better
>> solution, or workaround?
>
> We used to have that configurable, but the default level of
> information is rather useless when things go wrong, and *especially*
> when scriptlets fail. So recently that has changed to always enable
> debug.
>
> Alex