On Sat, Mar 27, 2021 at 3:31 AM Robert P. J. Day <rpj...@crashcourse.ca> wrote:
> On Fri, 26 Mar 2021, Andre McCurdy wrote:
> > On Fri, Mar 26, 2021 at 8:45 AM Robert P. J. Day <rpj...@crashcourse.ca> 
> > 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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150015): 
https://lists.openembedded.org/g/openembedded-core/message/150015
Mute This Topic: https://lists.openembedded.org/mt/81631340/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to