Re: [OE-core] RFC: design of network based PR service

[Mark Hatle <mark.hatle@windriver.com>]

On 4/28/11 5:02 PM, Chris Larson wrote:
> On Thu, Apr 28, 2011 at 2:23 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
>> Checksums and timestamps are not enough to determine a logical progression of
>> the components.
>>
>> We need something that informs the user where these changes fit in the grand
>> scheme of things.  Are they newer or older then a recipe of the same name (and
>> package version)?
> 
> I think we might want to stop using the term PR to describe what
> you're talking about here.  PR has historically had a quite specific
> meaning to us, given how bitbake has operated, and how stamps worked.
> It sounds like you want to formalize what we've likely all been doing
> manually -- PR .= ".1" or whatever in the .bbappend of a given layer.
> Do you think we really need a format string for this, or would
> introducing a new variable that's simply a list of extra version
> components, and which is used by the packaging classes, likely not by
> bitbake itself, get the job done? Am I grasping your need correctly?

I would like a format string so that for my products I can choose to do
arbitrary revision's in packages based on the data present in the recipes (and
elsewhere)..

But the way I see this, you are correct.  This is an effort to help automate the
PR .= ".1" and similar, but based on checksums and system configurations changes....

To me, "PR" stays as it is used (mostly) today.  As a way to indicate revisions
of a particular recipe...  The other changes can optionally site on top of that
based on the format string that the packaging back ends will adopt.  (We can
even make the default that the packaging revision = PR as the default string.)

--Mark