Re: [OE-core] [master][PATCH v2 0/6] Allow PR Service and hash equiv togther

["Richard Purdie" <richard.purdie@linuxfoundation.org>]

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