On Fri, 2021-07-16 at 11:44 -0500, Mark Hatle wrote:
>
> On 7/16/21 4:22 AM, Richard Purdie wrote:
> > On Thu, 2021-07-15 at 09:26 -0500, Mark Hatle wrote:
> > >
> > > On 7/15/21 8:56 AM, Richard Purdie wrote:
> > > > Breaking things down a bit, one thing I keep running into with our
> > > > current
> > > > codebase and metadata is that overrides are not clear. In my previous
> > > > email,
> > > > the example was:
> > > >
> > > > do_configure_class-native
> > > >
> > > > A human can usually spot "class-native" is and "configure" or
> > > > "configure_class-native" is not. Bitbake's parser struggles. It has
> > > > huge
> > > > internal lists including variables like x86_64 where it has to track
> > > > whether "64" in an override.
> > > >
> > > > One way of fixing this is to be explicit about overrides and use a
> > > > different
> > > > separator. See an example patch below I made to the quilt recipe using
> > > > ":"
> > > > instead to see how it looks. Personally, I think this looks like an
> > > > improvement.
> > > >
> > > > There are two challenges:
> > > >
> > > > a) The work of migration. Do we migrate piecemeal or with a flag day?
> > > > I'm not
> > > > sure piecemeal is even possible unfortunately.
> > > >
> > > > b) Some of the packaging code (at the very least) needs rewriting as it
> > > > accesses
> > > > both RDEPENDS_${PN} and puts ${PN} in OVERRIDES and accesses
> > > > RDEPENDS. I'm not
> > > > sure what else may be assuming this works.
> > >
> > > Ya, this is all over the packaging code. Should be trivial to move to
> > > treating
> > > it as a variable (and not override). I can help with this if you want.
> >
> > I've been pondering this a bit more and my preference is to move this to
> > use
> > overrides more explicitly.
>
> The part of the code I worked on, the override was used as an optimization to
> avoid:
>
> d.getVar("RDEPENDS_%s" % package) or d.getVar("RDEPENDS")
>
> (and similar for all of the other variables that could be package specific.)
>
> Overrides (at least to me) are system (or at least recipe) wide settings that
> allow you to 'override' key things. The package items, based on that
> definitely
> really aren't overrides -- they're package specific variables. (This is also
> why I suggested RDEPENDS[package] might actually be a better syntax.)
Overrides are one of the key things which make OE function as an architecture
and
how a lot of the "magic" in our metadata happens. There is a hierarchy of
overrides,
some are system wide some are local to specific functional areas but using them
for
packaging is a natural fit.
As such, I'm very strongly in favour of explicitly exposing that rather than
hiding
it.
FWIW the image class code also does something similar for IMAGE_CMD and image
types.
> I'm all for making override usage more clear to people. But in this ONE
> case, I
> don't think these are really overrides -- and worse they could cause confusion
> because they are ONLY overrides when packaging. So if you use the override
> chunk in something that doesn't affect a package specific setting it won't do
> anything. It also won't do anything on the functions (I think), as those are
> run before the override is loaded.
>
> Specific code I'm talking about BTW is:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/package_rpm.bbclass
>
> starting at line 287. (srcname is PN-src BTW)
>
> then the loop starting at 328. Iterates over PACKAGES and sets the override
> one
> at a time to the package name to get (conffiles, dirnames,
> summary/description,
> pkgv, pkgr, pkge, license, section, description, rdepends, rrecommends,
> rsuggests, rprovides, rreplaces, rconflicts, and I suspect a few others...)
>
> Note, I could make the above changes pretty quickly and just submit this as an
> implementation change in a few hours. I'd be happy to do that and look for
> other 'in-place' usages of d.setVar("OVERRIDE"... to see if there are other
> things like this.
As above, I'm very much of the opposite view, I think we want to promote this,
not remove it. Yes, you can emulate overrides with other forms of variable
access
but that really isn't how the system was designed to be used.
Cheers,
Richard
> >
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1276):
https://lists.openembedded.org/g/openembedded-architecture/message/1276
Mute This Topic: https://lists.openembedded.org/mt/84225642/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
