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

[Alexander Kanavin]

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