Re: [PATCH 2/7] shadow: add a -native recipe with customized utilities

From: Mark Hatle <mark.hatle@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 2/7] shadow: add a -native recipe with customized utilities
Date: Thu, 1 Sep 2011 11:54:04 -0500	[thread overview]
Message-ID: <4E5FB8AC.1070007@windriver.com> (raw)
In-Reply-To: <1314895291.19905.197.camel@phil-desktop>

On 9/1/11 11:41 AM, Phil Blundell wrote:
> 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.

What is it depending on for the target?  Is the shadow-utils or something now
required?  That doesn't seem to make sense to me -- other then we need a
passwd/group/shadow/gshadow file to work with.  As long as something can provide
those, we should be ok.

> 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 = ""

Yup, definitely a bug and should be fixed.  native and cross cases should not do
anything with useradd.

--Mark

> to the recipe, but it seems as though the class should probably be
> sorting this out for itself.
> 
> p.
> 
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core