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

[Alexander Kanavin]

I believe the culprit is likely this patch:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/rpm/files/0001-When-cross-installing-execute-package-scriptlets-wit.patch

As scriptlets are executed outside of rpm's chroot, they are being
written into system's /var/tmp, not rootfs's. This patch should
probably be amended to prepend the rootfs path when scriptlets are
written out, and then we should be sorted.

Alex

2018-06-25 21:43 GMT+02:00 Alexander Kanavin <alex.kanavin at gmail.com>:
> 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