On Wed, 2020-08-26 at 07:14 -0500, Mark Hatle wrote:
> This was actually the first thing I tried, and it was a complete
> failure. The problem is that all of the variables that we play with
> (not just PKGV/PKGR, as this impacts the RRECOMMENDS, RDEPENDS,
> etc..) all need this replacement done.
>
> Then they reference PKGR, which references EXTENDPRAUTO, which is a
> python variable which references PRAUTO which is what we actually
> care about.
>
> So really what we should be doing is putting in 'PRAUTO' (@PRAUTO@)
> as the replacement value and then replacing that later -- but we
> can't just do that since if it's blank then EXTENDPRAUTO works
> differently then if it's set.
>
> So we would need to wrap @EXTENDPRAUTO@, which "works".. but then we
> have to be able to expand it on the reading of the data as
> well. Which means modifications of every routine that reads the
> variables from the pkgdata store. But the various places where the
> variables are read in don't have access to the list of variables to
> expand -- so we might have to assume @...@ is used, which may work
> but I'm still worried about how complicated it gets.
I take the point about needing to use EXTENDPRAUTO, that makes sense.
So if in do_package we set EXTENDPRAUTO = "@EXTENDPRAUTO@", then in
do_packagedata we set PRAUTO then do a sed @EXTENDPRAUTO@ to
d.getVar("EXTENDPRAUTO"), we should then have the right data from that
point on?
I know its not a clean abstraction to two variables like you have now
but I think if we document what is happening, that doesn't matter. Its
not as if we're going to extend this to other variables regularly.
> With the current usage, the only place I've seen issues
> (buildhistory) is where
> they read the pkgdata directly and it never ends up in a
> datastore. Assuming it
> goes into a datastore then it's automatically expanded. (Other then
> buildhistory, I think all of the reader routines are located in
> lib/oe/packagedata.py -- so we should be able to scan for this stuff
> in the
> general case.)
>
> (I also don't want to move EXTENDPRAUTO into say do_package, because
> I believe
> the implementation of this is going to need to change in the future
> to support
> the use-case where a standard distribution is produced, a user
> consumes it --
> modifies a package and provides a variant of a few patches and just
> wants to
> extend the EXTENDPRAUTO with additional release information. I.e.
> initial
> version of EXTENDPRAUTO is .1, where the user's customization makes
> it .1.1...)
Agreed, but I think we can preserve it as above.
> > I'm also wondering if we should just inject the @XXXX@ change
> > (instead
> > of the delVar) into d directly at the start of do_package itself,
> > where
> > the existing bb.build.exec_func("package_get_auto_pr", d) call
> > is?
> >
> > That would then remove all the confusing localdata changes?
>
> Part of the reason I moved the change to a function as I thought it
> made it easier to read and understand the why.
Yes, having the function helps but it could be better again if we don't
need multiple datastores...
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#141856):
https://lists.openembedded.org/g/openembedded-core/message/141856
Mute This Topic: https://lists.openembedded.org/mt/76426267/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
