cpio_2.15.bb: delete superfluous ptest RDEPENDS on "ptest-runner"

Get rid of leftover cruft where a ptest-enabled recipe has a run-time
dependency on ptest-runner; this is now handled by ptest.bbclass.

This appears to be the only recipe in all of oe-core that had this.

Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>

---

On Wed, 3 Dec 2025 at 21:55, Robert P. J. Day via
lists.openembedded.org <rpjday=crashcourse.ca@lists.openembedded.org>
wrote:
> This appears to be the only recipe in all of oe-core that had this.

I see it in meta/recipes-devtools/quilt/quilt.inc as well.

Alex

On Wed, 3 Dec 2025 at 22:24, Alexander Kanavin via
lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org>
wrote:
> > This appears to be the only recipe in all of oe-core that had this.
>
> I see it in meta/recipes-devtools/quilt/quilt.inc as well.

Ah nevermind, that's DEPENDS/PACKAGE_WRITE_DEPS to be able to use the
ptest user.

Alex

On Wed, 2025-12-03 at 12:55 -0800, Robert P. J. Day wrote:
> 
> Get rid of leftover cruft where a ptest-enabled recipe has a run-time
> dependency on ptest-runner; this is now handled by ptest.bbclass.
> 
> This appears to be the only recipe in all of oe-core that had this.
> 
> Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
> 
> ---
> 
> diff --git a/meta/recipes-extended/cpio/cpio_2.15.bb b/meta/recipes-extended/cpio/cpio_2.15.bb
> index fa011251e2..8c31209f77 100644
> --- a/meta/recipes-extended/cpio/cpio_2.15.bb
> +++ b/meta/recipes-extended/cpio/cpio_2.15.bb
> @@ -69,7 +69,7 @@ do_install_ptest_base:append() {
>  DEPENDS:append:class-target = " ${@bb.utils.contains('PTEST_ENABLED', '1', 'ptest-runner', '', d)}"
>  PACKAGE_WRITE_DEPS:append:class-target = " ${@bb.utils.contains('PTEST_ENABLED', '1', 'ptest-runner', '', d)}"
> 
> -RDEPENDS:${PN}-ptest += "ptest-runner coreutils"
> +RDEPENDS:${PN}-ptest += "coreutils"
> 
>  PACKAGES =+ "${PN}-rmt"

The commit message is a little misleading which I'm a bit surprised at
given your love of correctness! :)

ptest.bbclass sets:

RRECOMMENDS:${PN}-ptest += "ptest-runner"

which is similar to but not equivalent to an RDEPENDS.

The reason is this package requires the user from that dependency, it
doesn't work without out. That is an RDEPENDS, not a RRECOMMENDS.

So whilst it isn't too obvious, I'd say the recipe is in fact correct?

Cheers,

Richard

On Tue, 9 Dec 2025 at 13:06, Richard Purdie via lists.openembedded.org
<richard.purdie=linuxfoundation.org@lists.openembedded.org> wrote:
> >  DEPENDS:append:class-target = " ${@bb.utils.contains('PTEST_ENABLED', '1', 'ptest-runner', '', d)}"
> >  PACKAGE_WRITE_DEPS:append:class-target = " ${@bb.utils.contains('PTEST_ENABLED', '1', 'ptest-runner', '', d)}"
> >
> > -RDEPENDS:${PN}-ptest += "ptest-runner coreutils"
> > +RDEPENDS:${PN}-ptest += "coreutils"
> The reason is this package requires the user from that dependency, it
> doesn't work without out. That is an RDEPENDS, not a RRECOMMENDS.
>
> So whilst it isn't too obvious, I'd say the recipe is in fact correct?

ptest-runner dependency is set in three different ways as seen above.
Are all three really necessary for ensuring the ptest user requirement
is fulfilled?

Alex

On Tue, 2025-12-09 at 13:19 +0100, Alexander Kanavin wrote:
> On Tue, 9 Dec 2025 at 13:06, Richard Purdie via
> lists.openembedded.org
> <richard.purdie=linuxfoundation.org@lists.openembedded.org> wrote:
> > >  DEPENDS:append:class-target = "
> > > ${@bb.utils.contains('PTEST_ENABLED', '1', 'ptest-runner', '',
> > > d)}"
> > >  PACKAGE_WRITE_DEPS:append:class-target = "
> > > ${@bb.utils.contains('PTEST_ENABLED', '1', 'ptest-runner', '',
> > > d)}"
> > > 
> > > -RDEPENDS:${PN}-ptest += "ptest-runner coreutils"
> > > +RDEPENDS:${PN}-ptest += "coreutils"
> > The reason is this package requires the user from that dependency,
> > it
> > doesn't work without out. That is an RDEPENDS, not a RRECOMMENDS.
> > 
> > So whilst it isn't too obvious, I'd say the recipe is in fact
> > correct?
> 
> ptest-runner dependency is set in three different ways as seen above.
> Are all three really necessary for ensuring the ptest user
> requirement
> is fulfilled?

user group dependencies between recipes are tricky to get right and
each of the above pieces does appear to fulfil a specific need. I have
a suspicion that yes, the bits are all needed.

I don't like that 'design' but right now, it is probably where we end
up.

Cheers,

Richard

On Tue, 9 Dec 2025, Richard Purdie wrote:

> On Tue, 2025-12-09 at 13:19 +0100, Alexander Kanavin wrote:
> > On Tue, 9 Dec 2025 at 13:06, Richard Purdie via
> > lists.openembedded.org
> > <richard.purdie=linuxfoundation.org@lists.openembedded.org> wrote:
> > > >  DEPENDS:append:class-target = "
> > > > ${@bb.utils.contains('PTEST_ENABLED', '1', 'ptest-runner', '',
> > > > d)}"
> > > >  PACKAGE_WRITE_DEPS:append:class-target = "
> > > > ${@bb.utils.contains('PTEST_ENABLED', '1', 'ptest-runner', '',
> > > > d)}"
> > > >
> > > > -RDEPENDS:${PN}-ptest += "ptest-runner coreutils"
> > > > +RDEPENDS:${PN}-ptest += "coreutils"
> > > The reason is this package requires the user from that dependency,
> > > it
> > > doesn't work without out. That is an RDEPENDS, not a RRECOMMENDS.
> > >
> > > So whilst it isn't too obvious, I'd say the recipe is in fact
> > > correct?
> >
> > ptest-runner dependency is set in three different ways as seen above.
> > Are all three really necessary for ensuring the ptest user
> > requirement
> > is fulfilled?
>
> user group dependencies between recipes are tricky to get right and
> each of the above pieces does appear to fulfil a specific need. I have
> a suspicion that yes, the bits are all needed.
>
> I don't like that 'design' but right now, it is probably where we end
> up.

  i'll have to re-read these last few posts to truly grok what is
happening here, but i appreciate your patience in explaining what is
clearly a bit of an obscure quirk.

rday