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

Richard Purdie richard.purdie at linuxfoundation.org
Fri Nov 23 17:26:51 UTC 2012


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.

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... :)

Cheers,

Richard





More information about the bitbake-devel mailing list