[OE-core] [PATCH 1/4] update-rc.d/useradd: Add additional dependecies

[Paul Eggleton]

On Tuesday 10 June 2014 15:53:19 Phil Blundell wrote:
> On Tue, 2014-06-10 at 07:38 -0700, Saul Wold wrote:
> > On 06/10/2014 04:57 AM, Phil Blundell wrote:
> > > On Thu, 2014-06-05 at 17:09 -0700, Saul Wold wrote:
> > >> These dependcies are needed to ensure that thier packages are created
> > >> correctly since these classes have runtime dependiences in their
> > >> packages
> > >> but they are not actually created yet at rootfs time.
> > > 
> > > Can you be more specific about why these
> > > dependecies/dependcies/dependiences are required?  I can't, offhand,
> > > think of any reason why update-rc.d requires initscripts for example.
> > 
> > It's more about having initscripts-funtions package built so that it's
> > available for the dynamic addition to the RDEPENDS later in
> > populate_pacakges_updatercd().  If initscripts is not built and we add
> > initscripts-functions to the RDEPENDS, the final rootfs will fail with
> > an unsatisfied dependency.
> 
> It seems to me that, if a given package ships an initscript which
> requires /etc/init.d/functions, it ought to be the responsibility of
> that package to rdepend on initscripts itself.  I'm not sure it's
> entirely desirable for update-rc.d to drag that dependency in.

It should be, however:

a) There are a bunch of recipes that don't currently do that, and you'll only 
find out there's a problem at do_rootfs time (or worse, if we went a step 
further and didn't even dynamically add the RDEPENDS, at runtime when the 
service fails to start).

b) Saul's patch adds a build-time dependency, not a runtime one, and the 
initscripts recipe only packages files so the impact is fairly trivial even if 
it's not going to be built through other dependencies anyway.

> > > Also, what's going on with the PACKAGESPLITFUNCS_remove_class-nativesdk?
> > 
> > We don't need to run that funtion to create the nativesdk sysroot, so
> > don't run it.
> 
> Fair enough, but this seems like an unrelated change (and one which
> isn't covered by the patch summary or description).  Shouldn't that be
> in a separate commit?

The patch has been merged now, but FWIW it seems like it probably should have 
been a separate one.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre