Re: [OE-core] [PATCH 1/3] useradd: Fix issues with useradd dependencies

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

On Thu, 2023-12-07 at 13:58 +0100, Alexander Kanavin wrote:
> On Thu, 7 Dec 2023 at 13:45, Eilís 'pidge' Ní Fhlannagáin
> <pidge@baylibre.com> wrote:
> > -USERADDSETSCENEDEPS:class-target = "${MLPREFIX}base-passwd:do_populate_sysroot_setscene pseudo-native:do_populate_sysroot_setscene shadow-native:do_populate_sysroot_setscene ${MLPREFIX}shadow-sysroot:do_populate_sysroot_setscene"
> > +USERADDSETSCENEDEPS:class-target = "${MLPREFIX}base-passwd:do_populate_sysroot_setscene pseudo-native:do_populate_sysroot_setscene shadow-native:do_populate_sysroot_setscene ${MLPREFIX}shadow-sysroot:do_populate_sysroot_setscene ${@' '.join(['%s:do_populate_sysroot_setscene' % pkg for pkg in d.getVar("USERADD_DEPENDS").split()])}"
> 
> I'd like to clarify: do all these recent fixes mean that we can also
> add dynamic library dependencies of shadow-native into this list (it
> becomes an issue with latest versions of shadow currently not in
> oe-core)?
> 
> Specifically, this commit
> 
> https://git.yoctoproject.org/poky-contrib/commit/?h=akanavin/package-version-updates&id=9fdbe321fa53785cc35bd1bb4054366383ef20e5
> 
> doing
> 
> -USERADDSETSCENEDEPS:class-target =
> "${MLPREFIX}base-passwd:do_populate_sysroot_setscene
> pseudo-native:do_populate_sysroot_setscene
> shadow-native:do_populate_sysroot_setscene
> ${MLPREFIX}shadow-sysroot:do_populate_sysroot_setscene"
> +USERADDSETSCENEDEPS:class-target =
> "${MLPREFIX}base-passwd:do_populate_sysroot_setscene \
> + pseudo-native:do_populate_sysroot_setscene \
> + shadow-native:do_populate_sysroot_setscene \
> + attr-native:do_populate_sysroot_setscene \
> + libbsd-native:do_populate_sysroot_setscene \
> + libmd-native:do_populate_sysroot_setscene \
> + ${MLPREFIX}shadow-sysroot:do_populate_sysroot_setscene"
> 
> has been rejected by RP with the suggestion that shadow should be
> linked statically, but now I'm not sure if the argument still holds.

After my recent change, we could in theory do this as bitbake might be
able to make it work. It does run the risk of circular dependencies and
these setscene inter-task dependencies are *horrible* in general from
an sstate perspective though as my other comments about these
dependencies leading to poor behaviour still stand.

To be clear about what you're saying above, you're saying that if any
of those native dependencies are missing, we cannot use/install the
sstate object. We have to defer installing that sstate until all the
others are downloaded and available too.

My preference is still to statically link shadow to avoid this pretty
horrible side effect.

Cheers,

Richard