[oe] Heads up: stricter package checking with newer opkg versions

[John Willis]

Koen,

Thanks for the mail. Looks like the error handling that pushes the issues up
to the surface came in rev 394/395 of OPKG.

> Opkg > r387 propagates all errors, so if your package is broken it
> might
> have installed before, but won't anymore.
> 
> Things like creating a symlink over an existing dir (e.g. udev 141
> after
> another package installed a udev rule already) or creating a dir with
> the insufficient permissions and installing a file into it (adobe-
> fonts)
> now fail.

Yep, there are a good handful of occurrences' of these recently exposed
recipe bugs.

Some that have come to light in the last day or so are below.

(offline root mode: not running xorg-minimal-fonts.preinst)
opkg: Cannot create symlink from ./usr/lib/X11/fonts to
'/usr/share/fonts/X11/': File exists

(offline root mode: not running devicekit-power.preinst)
opkg: /someoedir/lib/udev/rules.d/95-devkit-power-battery-recall-ibm.rules:
Permission denied

(offline root mode: not running networkmanager.preinst)
opkg: /someoedir/lib/udev/rules.d/77-nm-zte-port-types.rules: Permission
denied

(offline root mode: not running udev.preinst)
opkg: Cannot create symlink from ./lib/udev/rules.d to '/etc/udev/rules.d':
File exists

(offline root mode: not running font-adobe-75dpi.preinst)
opkg: /someoedir/usr/lib/X11/fonts/75dpi/ncenBI10.pcf.gz: Permission denied

I am sure there will be a lot more but let's just get fixes in, better error
propagation can't really be a bad thing.

> If building an image suddenly starts failing, have a look at the log
> and
> see what's wrong. Most likely the package is trying to do something
> wrong and we need to fix that.
> 
> I'm testing a fix for the udev symlink currently.

Yep, a quick and dirty way of seeing any/all OPKG errors in the rootfs build
is to grep for 'opkg:' in the log file, you will see multiple instances
message of the error but that's normal.

These errors used to also be logged but opkg passed them over as non
critical, it now seems to not be the case. So checking existing rootfs logs
may show up other packages with snags.

Thanks,

John