what should be easy questions about packagegroups, inspired by my
running across some puzzling packagegroup recipes in my travels
recently. (i'll start with examples out of oe-core).

first, as with any other recipe, given a "trivial" packagegroup
like, say, packagegroup-core-eclipse-debug.bb:

SUMMARY = "Remote debugging tools for Eclipse integration"

inherit packagegroup

RDEPENDS_${PN} = "\
gdbserver \
tcf-agent \
openssh-sftp-server \
"

there is no need to add a "PROVIDES" line since every recipe file
automatically provides its own name. so far, so good.

if we move up to packagegroup-core-nfs.bb, note how this recipe file
defines two additional packagegroups, and has to add a PROVIDES line
in order to make those new names accessible:

PROVIDES = "${PACKAGES}"
PACKAGES = "${PN}-server ${PN}-client"

SUMMARY_${PN}-client = "NFS client"
RDEPENDS_${PN}-client = "nfs-utils-client"

SUMMARY_${PN}-server = "NFS server"
RDEPENDS_${PN}-server = "\
nfs-utils \
nfs-utils-client \
"

so the question is, must one supply a PROVIDES line for any
packagegroup names above and beyond the one that comes with the recipe
file itself? i ask what seems like a dumb question as i've run across
packagegroup recipe files that define multiple additional
packagegroups, but do not add them to the PROVIDES line. what is that
supposed to represent?

rday

On Fri, Mar 26, 2021 at 8:45 AM Robert P. J. Day <rpjday@...> wrote:

what should be easy questions about packagegroups, inspired by my
running across some puzzling packagegroup recipes in my travels
recently. (i'll start with examples out of oe-core).

first, as with any other recipe, given a "trivial" packagegroup
like, say, packagegroup-core-eclipse-debug.bb:

SUMMARY = "Remote debugging tools for Eclipse integration"

inherit packagegroup

RDEPENDS_${PN} = "\
gdbserver \
tcf-agent \
openssh-sftp-server \
"

there is no need to add a "PROVIDES" line since every recipe file
automatically provides its own name. so far, so good.

if we move up to packagegroup-core-nfs.bb, note how this recipe file
defines two additional packagegroups, and has to add a PROVIDES line
in order to make those new names accessible:

PROVIDES = "${PACKAGES}"
PACKAGES = "${PN}-server ${PN}-client"

SUMMARY_${PN}-client = "NFS client"
RDEPENDS_${PN}-client = "nfs-utils-client"

SUMMARY_${PN}-server = "NFS server"
RDEPENDS_${PN}-server = "\
nfs-utils \
nfs-utils-client \
"

so the question is, must one supply a PROVIDES line for any
packagegroup names above and beyond the one that comes with the recipe
file itself? i ask what seems like a dumb question as i've run across
packagegroup recipe files that define multiple additional
packagegroups, but do not add them to the PROVIDES line. what is that
supposed to represent?

PROVIDES sets up a name which can be used as DEPENDS (ie a build time
dependency) in other recipes. If PROVIDES contains more than one name,
they all just become aliases for each other.

Since packagegroup recipes only define run time dependencies, nothing
should have a build time dependency on a packagegroup recipe... and so
there's no obvious reason to set PROVIDES to anything. Leaving the
default will be fine (although it won't be used for anything).

On Fri, 26 Mar 2021, Andre McCurdy wrote:

On Fri, Mar 26, 2021 at 8:45 AM Robert P. J. Day <rpjday@...> wrote:

what should be easy questions about packagegroups, inspired by my
running across some puzzling packagegroup recipes in my travels
recently. (i'll start with examples out of oe-core).

first, as with any other recipe, given a "trivial" packagegroup
like, say, packagegroup-core-eclipse-debug.bb:

SUMMARY = "Remote debugging tools for Eclipse integration"

inherit packagegroup

RDEPENDS_${PN} = "\
gdbserver \
tcf-agent \
openssh-sftp-server \
"

there is no need to add a "PROVIDES" line since every recipe file
automatically provides its own name. so far, so good.

if we move up to packagegroup-core-nfs.bb, note how this recipe file
defines two additional packagegroups, and has to add a PROVIDES line
in order to make those new names accessible:

PROVIDES = "${PACKAGES}"
PACKAGES = "${PN}-server ${PN}-client"

SUMMARY_${PN}-client = "NFS client"
RDEPENDS_${PN}-client = "nfs-utils-client"

SUMMARY_${PN}-server = "NFS server"
RDEPENDS_${PN}-server = "\
nfs-utils \
nfs-utils-client \
"

so the question is, must one supply a PROVIDES line for any
packagegroup names above and beyond the one that comes with the recipe
file itself? i ask what seems like a dumb question as i've run across
packagegroup recipe files that define multiple additional
packagegroups, but do not add them to the PROVIDES line. what is that
supposed to represent?

PROVIDES sets up a name which can be used as DEPENDS (ie a build
time dependency) in other recipes. If PROVIDES contains more than
one name, they all just become aliases for each other.

Since packagegroup recipes only define run time dependencies,
nothing should have a build time dependency on a packagegroup
recipe... and so there's no obvious reason to set PROVIDES to
anything. Leaving the default will be fine (although it won't be
used for anything).

i could have *sworn* that, once upon a time, i verified (in some
weird way) the necessity for the PROVIDES line in a packagegroup, but
it seems i was mistaken. so if this is the case, then why do a couple
of OE packagegroup recipe files contain such a line?

packagegroup-base.bb
====================

inherit packagegroup

PROVIDES = "${PACKAGES}" <=== ?????
PACKAGES = ' \
packagegroup-base \
packagegroup-base-extended \
packagegroup-distro-base \
packagegroup-machine-base \
... etc etc ...

surely this is not meant to alias all those distinct packagegroup
definitions.

rday

p.s. see also,
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb

On Sat, Mar 27, 2021 at 3:31 AM Robert P. J. Day <rpjday@...> wrote:

On Fri, 26 Mar 2021, Andre McCurdy wrote:

On Fri, Mar 26, 2021 at 8:45 AM Robert P. J. Day <rpjday@...> wrote:

what should be easy questions about packagegroups, inspired by my
running across some puzzling packagegroup recipes in my travels
recently. (i'll start with examples out of oe-core).

first, as with any other recipe, given a "trivial" packagegroup
like, say, packagegroup-core-eclipse-debug.bb:

SUMMARY = "Remote debugging tools for Eclipse integration"

inherit packagegroup

RDEPENDS_${PN} = "\
gdbserver \
tcf-agent \
openssh-sftp-server \
"

there is no need to add a "PROVIDES" line since every recipe file
automatically provides its own name. so far, so good.

if we move up to packagegroup-core-nfs.bb, note how this recipe file
defines two additional packagegroups, and has to add a PROVIDES line
in order to make those new names accessible:

PROVIDES = "${PACKAGES}"
PACKAGES = "${PN}-server ${PN}-client"

SUMMARY_${PN}-client = "NFS client"
RDEPENDS_${PN}-client = "nfs-utils-client"

SUMMARY_${PN}-server = "NFS server"
RDEPENDS_${PN}-server = "\
nfs-utils \
nfs-utils-client \
"

so the question is, must one supply a PROVIDES line for any
packagegroup names above and beyond the one that comes with the recipe
file itself? i ask what seems like a dumb question as i've run across
packagegroup recipe files that define multiple additional
packagegroups, but do not add them to the PROVIDES line. what is that
supposed to represent?

PROVIDES sets up a name which can be used as DEPENDS (ie a build
time dependency) in other recipes. If PROVIDES contains more than
one name, they all just become aliases for each other.

Since packagegroup recipes only define run time dependencies,
nothing should have a build time dependency on a packagegroup
recipe... and so there's no obvious reason to set PROVIDES to
anything. Leaving the default will be fine (although it won't be
used for anything).

i could have *sworn* that, once upon a time, i verified (in some
weird way) the necessity for the PROVIDES line in a packagegroup, but
it seems i was mistaken. so if this is the case, then why do a couple
of OE packagegroup recipe files contain such a line?

packagegroup-base.bb
====================

inherit packagegroup

PROVIDES = "${PACKAGES}" <=== ?????

That line dates back to 2007, when packagegroup-base.bb was still
called task-base.bb:

https://git.openembedded.org/openembedded-core/commit/?id=ba9dd5228c290c96c622fb82964e49ce2511a1e9

Maybe it had some legitimate use back then?

Really the whole "base packagegroups" concept is showing its age. No
one creating a new machine config today ponders on whether or not to
enable the pci, pcmcia, phone, etc machine features.
packagegroup-base.bb contains a lot of useless cruft... the bogus
PROVIDES line is just the tip of the iceberg.

PACKAGES = ' \
packagegroup-base \
packagegroup-base-extended \
packagegroup-distro-base \
packagegroup-machine-base \
... etc etc ...

surely this is not meant to alias all those distinct packagegroup
definitions.

rday

p.s. see also,
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb

On Sat, 27 Mar 2021, Andre McCurdy wrote:

On Sat, Mar 27, 2021 at 3:31 AM Robert P. J. Day <rpjday@...> wrote:

On Fri, 26 Mar 2021, Andre McCurdy wrote:

On Fri, Mar 26, 2021 at 8:45 AM Robert P. J. Day <rpjday@...> wrote:

what should be easy questions about packagegroups, inspired by my
running across some puzzling packagegroup recipes in my travels
recently. (i'll start with examples out of oe-core).

first, as with any other recipe, given a "trivial" packagegroup
like, say, packagegroup-core-eclipse-debug.bb:

SUMMARY = "Remote debugging tools for Eclipse integration"

inherit packagegroup

RDEPENDS_${PN} = "\
gdbserver \
tcf-agent \
openssh-sftp-server \
"

there is no need to add a "PROVIDES" line since every recipe file
automatically provides its own name. so far, so good.

if we move up to packagegroup-core-nfs.bb, note how this recipe file
defines two additional packagegroups, and has to add a PROVIDES line
in order to make those new names accessible:

PROVIDES = "${PACKAGES}"
PACKAGES = "${PN}-server ${PN}-client"

SUMMARY_${PN}-client = "NFS client"
RDEPENDS_${PN}-client = "nfs-utils-client"

SUMMARY_${PN}-server = "NFS server"
RDEPENDS_${PN}-server = "\
nfs-utils \
nfs-utils-client \
"

so the question is, must one supply a PROVIDES line for any
packagegroup names above and beyond the one that comes with the recipe
file itself? i ask what seems like a dumb question as i've run across
packagegroup recipe files that define multiple additional
packagegroups, but do not add them to the PROVIDES line. what is that
supposed to represent?

PROVIDES sets up a name which can be used as DEPENDS (ie a build
time dependency) in other recipes. If PROVIDES contains more than
one name, they all just become aliases for each other.

Since packagegroup recipes only define run time dependencies,
nothing should have a build time dependency on a packagegroup
recipe... and so there's no obvious reason to set PROVIDES to
anything. Leaving the default will be fine (although it won't be
used for anything).

i could have *sworn* that, once upon a time, i verified (in some
weird way) the necessity for the PROVIDES line in a packagegroup, but
it seems i was mistaken. so if this is the case, then why do a couple
of OE packagegroup recipe files contain such a line?

packagegroup-base.bb
====================

inherit packagegroup

PROVIDES = "${PACKAGES}" <=== ?????

That line dates back to 2007, when packagegroup-base.bb was still
called task-base.bb:

https://git.openembedded.org/openembedded-core/commit/?id=ba9dd5228c290c96c622fb82964e49ce2511a1e9

Maybe it had some legitimate use back then?

Really the whole "base packagegroups" concept is showing its age. No
one creating a new machine config today ponders on whether or not to
enable the pci, pcmcia, phone, etc machine features.
packagegroup-base.bb contains a lot of useless cruft... the bogus
PROVIDES line is just the tip of the iceberg.

well, unless there are any objections, i'll submit a patch to get
rid of those two useless PROVIDES line (or however many i find). we
can at least start there.

rday

On Fri, 26 Mar 2021, Andre McCurdy wrote:

... snip ...

PROVIDES sets up a name which can be used as DEPENDS (ie a build
time dependency) in other recipes. If PROVIDES contains more than
one name, they all just become aliases for each other.

Since packagegroup recipes only define run time dependencies,
nothing should have a build time dependency on a packagegroup
recipe... and so there's no obvious reason to set PROVIDES to
anything. Leaving the default will be fine (although it won't be
used for anything).

can someone verify that packagegroup recipe files indeed do not need
a PROVIDES line? if not, i can submit a patch to toss them from
meta-openembedded as well. it seems(?) fairly obvious that those lines
are superfluous, but i've been surprised before.

rday