Re: [docs] [PATCH] ref-manual: clarify use of "PACKAGE_ARCH" in a packagegroup

On Fri, 26 Jun 2026, Quentin Schulz wrote:

>
>
> On 6/19/26 7:10 PM, Robert P. J. Day wrote:
> > On Fri, 19 Jun 2026, Quentin Schulz wrote:
> >
> > > Hi Robert,
> > >
> > > On 6/16/26 6:46 PM, Robert P. J. Day via lists.yoctoproject.org wrote:
> > > >
> > > > Warn the developer that if they need to set "PACKAGE_ARCH" in a
> > > > custom packagegroup file, that setting must precede the "inherit
> > > > packagegroup" line in the packagegroup recipe file.
> > > >
> > > > Signed-off-by: Robert P. J. Day <[email protected]>
> > > >
> > > > ---
> > > >
> > > > diff --git a/documentation/ref-manual/classes.rst
> > > > b/documentation/ref-manual/classes.rst
> > > > index 95e07f85a..839a89d4b 100644
> > > > --- a/documentation/ref-manual/classes.rst
> > > > +++ b/documentation/ref-manual/classes.rst
> > > > @@ -2130,6 +2130,18 @@ section in the Yocto Project Development Tasks
> > > > Manual.
> > > >
> > > >    Previously, this class was called the ``task`` class.
> > > >
> > > > +.. note::
> > > > +
> > > > +   If you're defining a packagegroup and need to set::
> > > > +
> > > > +      PACKAGE_ARCH = ${MACHINE_ARCH}
> > > > +
> > >
> > > OK so reading this I was like "but who would need to do this?
> > > packagegroups
> > > are only supposed to include other packages and not compile anything!
> > >
> > > Then I looked in OE-Core, and there are as many packagegroups with
> > > PACKAGE_ARCH set than without. It seems that the need comes from using
> > > MACHINE_FEATURES or other knobs that depend on some configuration
> > > variable.
> > >
> > > I think it'd be nice to document this (if not already, but since you're
> > > scouring the docs now maybe you'd come across something like that?).
> > >
> > > I'm thinking this is a big enough footgun that we may want to document the
> > > order in the variable glossary as well.
> >
> >    richard purdie explained this once upon a time:
> >
> > https://lists.openembedded.org/g/openembedded-core/topic/patch_4_4_package_add/87011325
> >
>
> That sounds like a great thing to add to the docs. Both here and in
> the variable glossary for PACKAGE_ARCH as well I think?
>
> Do you agree? Would you mind sending a patch for this?

  i don't think i'm the right person for that as i don't *fully*
understand what is going on under the hood, and here's why.

  while richard's explanation involves using the variable
${TUNE_PKGARCH}, with a quick scan over all the layers i have checked
out, there are even more packagegroups that are assigning
${MACHINE_ARCH}. and i'm sure i read somewhere that there were at
least two reasons for setting MACHINE_ARCH in a packagegroup recipe
file, one of which was package renaming but i don't remember the other
one.

  if all you're looking for is something like:

"For some packagegroups, it is sometimes necessary to set the
MACHINE_ARCH variable to one of .... If that's the case, that
assignment has to be placed above the 'inherit packagegroup' line."

  but that sort of explanation is maddeningly uninformative, so
someone else who knows more about it should probably do that. but,
yes, that definitely merits a ".. warning::" somewhere.

rday