Re: [OE-core] [PATCH] file: Remove unneccessary override of PACKAGECONFIG for native

["Andre McCurdy" <armccurdy@gmail.com>]

On Wed, May 13, 2020 at 10:14 AM Peter Kjellerstedt
<peter.kjellerstedt@axis.com> wrote:
>
> > -----Original Message-----
> > From: Andre McCurdy <armccurdy@gmail.com>
> > Sent: den 13 maj 2020 00:20
> > To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> > Cc: OE Core mailing list <openembedded-core@lists.openembedded.org>
> > Subject: Re: [OE-core] [PATCH] file: Remove unneccessary override of
> > PACKAGECONFIG for native
> >
> > On Tue, May 12, 2020 at 2:43 PM Peter Kjellerstedt
> > <peter.kjellerstedt@axis.com> wrote:
> > >
> > > There is no reason to set PACKAGECONFIG_class-native to the same value
> > > as the default PACKAGECONFIG.
> >
> > End users often don't know how to safely change PACKAGECONFIG from a
> > .bbappend and might try PACKAGECONFIG += "foo" or PACKAGECONFIG_append
> > = " foo" without realising that it could affect more than just the
> > target build.
> >
> > Have an explicit PACKAGECONFIG_class-native keeps the native config
> > stable for users who haven't yet learning through experience that the
> > safe way to change PACKAGECONFIG is PACKAGECONFIG_append_class-target
> > = " foo".
> >
> > So although this PACKAGECONFIG_class-native may seem redundant to the
> > experts, it helps make OE more robust for regular users.
>
> I have to disagree with this. Having just PACKAGECONFIG ??= "zlib"
> makes for a more consistent behavior between the different classes.

I don't see why a consistent configuration between the different
classes is a goal. We should instead try to keep them independent so
that changes to one don't accidentally affect the others. The
configuration for the target is determined by the functionality
required in the final image (ie something determined by the user) and
the configuration for native and nativesdk is mostly determined by the
requirements of the build environment. The requirements for the build
environment are fairly static and not something a typical user would
want to mess with.

> E.g., if someone would add a .bbappend with PACKAGECONFIG = "zlib
> bz2", with the current recipe the behavior would be different when
> building file and nativesdk-file compared to file-native (or actually
> file-replacement-native as file-native is in ASSUME_PROVIDED). With
> only the default PACKAGECONFIG, the result would be the same also
> for file-native.

Having an over-ride for native but not considering nativesdk is
certainly an issue which seems to affect many recipes in oe-core. But
the fix should be adding an over-ride for nativesdk rather than
removing the over-ride for native.

(I don't know why this problem doesn't come up more often. Perhaps
because while there are users who like to change PACKAGECONFIG values
and users who build for nativesdk the overlap between them is actually
quite small?).

> A quick grep through OE-Core also seems to agree with me. There are
> a couple of other recipes that sets PACKAGECONFIG_class- defaults,
> but then it's due to the default for, e.g., native being different
> from target. The only other recipe I could find that sets multiple
> identical PACKAGECONFIG defaults is openssl.

Yes. Unfortunately making recipes robust for users who want to change
PACKAGECONFIG values doesn't seem to be a high priority for oe-core.
Why else would default PACKAGECONFIG values be assigned with ??=
instead of ?= other than as a trap for new users?