[Openembedded-architecture] Changes that switching from smart to dnf will cause
Richard Purdie
richard.purdie at linuxfoundation.org
Tue Feb 14 14:29:00 UTC 2017
On Tue, 2017-02-14 at 16:04 +0200, Alexander Kanavin wrote:
> 6. Things that need to run on target during package installation
> should
> go into pkg_postinst_ontarget()
>
> Previously, the way to achieve this was:
>
> pkg_postinst_PACKAGENAME() {
> if [ x"$D" = "x" ]; then
> # Actions to carry out on the device go here
> else
> exit 1
> fi
> }
>
> The new way is simply:
>
> pkg_postinst_ontarget_PACKAGENAME() {
> # Actions to carry out on the device go here
> }
>
> The old way still works, but is deprecated and will produce a
> warning. I
> understand this change is orthogonal to dnf, but the current design
> is
> flawed and now is a chance to fix it. The reasons are:
>
> 1) Code is hard to read; it is not obvious that 'if D is defined
> then
> exit 1' means 'defer what follows to first boot during package
> cross-install'.
>
> 2) Worse, this hides actual errors in the scriptlets; there is no
> difference between scriptlet failing because it's intended to be run
> on
> target and scriptlet failing because there's a bug or a regression
> somewhere. I've already found broken scriptlets where the brokenness
> was
> hidden this way (in meta-selftest/recipes-
> test/postinst/postinst_1.0.bb)
>
> Plain pkg_postinst() without special tricks works exactly as before.
I'm not sure I agree with this. I do understand your concerns however
its not quite as clear cut as you make out.
We have situations where we simply don't know in advance if a given
postinst is going to be able to work at rootfs construction time or
not. As an example, take the fontconfig postinst. This runs under qemu
emulation. That emulation can work for some arches and not others. We
don't really want to have to mark things up to indicate which work and
which don't. Worse, some target optimisations might work and others
might not.
I'd therefore like to see this change disentangled from the rpm change
and considered separately, if its something we really want to do which
I remain unconvinced about.
Cheers,
Richard
More information about the Openembedded-architecture
mailing list