On Thu, 2011-09-01 at 15:46 +0100, Phil Blundell wrote:
> I just tried using useradd.bbclass for the first time (in an effort to
> make dbus installable on a readonly-rootfs) and it doesn't seem to be
> working very well for me.
> 
> The root of my problem seems to be the code below.  As far as I can
> tell, what's happening is that process_root_flag() consumes all the
> command line arguments to useradd, which means that the subsequent call
> to getopt() in process_flags() just returns immediately because there is
> nothing left for it to do.  The upshot of all this is that the switches
> on the command line are simply ignored and useradd doesn't do what I
> wanted.
> 
> Is anybody else using this code successfully in oe-core with a
> nontrivial USERADD_PARAM?

So, I added a strategic "optind = 1" to useradd.c and the situation
seems to have improved a bit.  However, I've encountered a couple of
other issues which are slightly annoying:

a) with the attached patch, dbus itself no longer requires a postinst to
be run at boot time.  Which is cool.  Unfortunately, inheriting useradd
causes it to now depend on shadow (which wasn't previously in my image)
and shadow itself isn't currently amenable to read-only-rootfs either so
my image build still fails.  I guess the answer to this is to have
shadow excluded (by some or other mechanism) during rootfs construction
for non-package-management-enabled images.

b) the useradd.bbclass stuff seems to try to apply itself to
virtclass-native packages as well, which was causing an error during
do_install() for dbus-native.  I worked around this by adding

USERADD_PARAM_${PN}_virtclass-native = ""
GROUPADD_PARAM_${PN}_virtclass-native = ""

to the recipe, but it seems as though the class should probably be
sorting this out for itself.

p.