[OE-core] [PATCH] rootfs_ipk: respect ONLINE_PACKAGE_MANAGEMENT

[Richard Purdie]

On Thu, 2011-05-19 at 11:31 +0100, Phil Blundell wrote:
> On Thu, 2011-05-19 at 11:15 +0100, Richard Purdie wrote:
> > We have postinstalls that require to run on the target device. If
> > they're present, we need opkg there to run them, or at least some kind
> > of script to handle that and I think both cases have a requirement on
> > that directory (the rpm backend has a suitable script).
> > 
> > So the current patches which just don't create it don't really address
> > the problem. At the very least the image generation should error if
> > these types of postinstall are present which I guess is my real concern.
> 
> Ah, I see what you mean now.  Yes, it is true that packages which expect
> to get their postinst run on the target will lose in this case.  But,
> practically speaking, this is not likely to be too much of a limitation:
> devices which have O_P_M=none tend to be the same ones that have their
> root filesystem on readonly media, so running postinsts on the target is
> likely to be futile anyway.  (Also, O_P_M=none targets will generally
> not install opkg in their rootfs in any case.)
>
> I agree it would be a good thing for the build to emit an error in this
> case rather than just causing the postinsts to silently not run.  I
> guess the ideal way of dealing with this would be:
> 
> a) introduce a new variable, TARGET_FILESYSTEM_READONLY or some such,
> and make it an error for there to be any packages left in "install ok
> unpacked" at the end of rootfs construction if this flag is set;
> 
> b) for the case where O_P_M="none" but T_F_R is not set, provide an
> additional postprocessor to distill the opkg status file down to just
> the bits that are needed for postinst running, and also provide some
> lightweight script to run the postinsts and then clean up afterwards.

Agreed. I'd like to raise one other issue which is the number of
variables we need to control these things which are effectively binary
flags. I'm leaning towards having a small number of variables containing
flags which trigger certain behaviours. In this case the obvious choices
would be:

IMAGE_FEATURES = "readonly nopackagemanager"

but there are other things which make sense as DISTRO_FEATURES (e.g.
nox11) or MACHINE_FEATURES.

We have these variables and I know Chris has some patches submitted to
improve our handling of such variables. I'm coming down in favour of
extending these into some of these use cases too though.

Thoughts?

Cheers,

Richard