[bitbake-devel] [OE-core] RFC: Versioning of git recipes (and incremental PR)

[Otavio Salvador]

On Fri, Nov 23, 2012 at 3:26 PM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> Currently we have some rather complex and potentially broken code in the
> fetcher code to deal with the the fact that you don't get incremental
> versions from git revisions easily. The system currently has a database
> and generates incremental numbers so PV becomes something like:
>
> 0.1+git1-deadbeefdecafbad
>
> or for perverse recipes with more than one git source:
>
> 0.1+git1-deadbeefdecafbad-git3-decafbaddeadbeef
>
> We currently have a bug that this doesn't interact well with sstate
> feeds since you have to have a single persistdb for any given sstate
> feed. It won't break in that sstate will just not be used but that is
> inefficient.
>
> The fact we need to have increasing values in the field is a very
> similar problem to the incremental PR for package fields that we're
> addressing with the PR server.

Yes; I had problem using GIT with PR server last time I tried it.

Good that it's being worked on/has been fixed.

> I've therefore taken a step back and considered things and am proposing
> that we adapt the PR server to handle this issue and then drop the code
> from the fetcher. The rough implementation of this would mean that:
>
> * PV would become 0.1+gitAUTOINC-deadbeefdecafbad-decafbaddeadbeef
>
> * We'd have one incrementing value rather than several.
>
> * That the code would detect a PV containing AUTOINC and set PKGV to the
> same thing with AUTOINC replaced with the "auto PR" value
>
> * We'd do this in parallel with the usual auto PR value. In PR server
> terms this means likely in the same data table using "git-PV" as the key
> and just call the API with a different key name.
>
> * If the PR server isn't running, this would just set PKGV to PV but
> with AUTOINC set to 0. This would mean you wouldn't get updating package
> feeds but usual image creation would be just fine.
>
> * There are some complexities for data import and export we need to
> consider and work through.
>
> All things considered I think this would be a nice improvement and allow
> us to have one good set of "incremental" code and simplify the fetchers.
>
> I'm open to discussion... :)

I like to idea of a single updating place. What I dislike is AUTOINC
not being taken care in the fetcher.

In this case any GIT revision changes, the AUTOINC won't bump as usual
(without PR server)?

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br