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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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