[OE-core] [PATCH 2/7] shadow: add a -native recipe with customized utilities
Richard Purdie
richard.purdie at linuxfoundation.org
Thu Sep 1 21:59:20 UTC 2011
On Thu, 2011-09-01 at 20:44 +0100, Phil Blundell wrote:
> On Thu, 2011-09-01 at 12:25 -0500, Mark Hatle wrote:
> > On 9/1/11 11:58 AM, Phil Blundell wrote:
> > > And, I guess, if you want to support online package management then it
> > > does make some sense to have the shadow utils there. But I don't
> > > need/want that in my configuration.
> >
> > Does busybox or something else provide a compatible adduser? If so maybe a
> > virtual RDEPENDS is more reasonable in this case.
>
> I'm not sure offhand (it's actually useradd, not adduser, for what
> that's worth) but, even if busybox does provide those applets, that
> probably isn't quite the point. The issue here is that I don't really
> want to have any implementation of useradd at all on the target system;
> using one from busybox would be a bit less bad than requiring standalone
> shadow, but still not really ideal.
>
> One workaround would be to weaken the RDEPENDS to an RRECOMMENDS, which
> would allow me to declare it as a BAD_RECOMMENDATION. Or I guess we
> could make it be a virtual and I could then provide a dummy-useradd
> package which satisfies the dependency but doesn't actually install any
> files.
>
> The approach we take with update-rc.d is to let it be installed and then
> have rootfs_ipk rip it back out again after image construction is done,
> but this won't work with shadow as it stands due to the postinst issue
> in that package. So a third option would be to find a way to finesse
> the postinst thing somehow and then use the same rootfs_ipk logic with
> shadow too.
The latter sounds like what we'll need to do. I haven't looked at shadow
to see what kind of finessing is required though...
Does opkg have any notion of bitbake's ASSUME_PROVIDED?
Cheers,
Richard
More information about the Openembedded-core
mailing list