[oe] [PATCH] classes/gitpkgv.bbclass: add GITPKGVTAG that uses 'git describe'

[Otavio Salvador]

On Thu, Dec 16, 2010 at 19:52, Martin Jansa <martin.jansa at gmail.com> wrote:
> On Thu, Dec 16, 2010 at 02:07:37PM -0200, Otavio Salvador wrote:
>> Using ${GITPKGVTAG} allows for automatic versioning based on the
>> repository tags. For those that doesn't want to use it, ${GITPKGV} is
>> still available.
>
> Thanks for merging it to one bbclass. IMHO looks much better now.
> Consider providing examples and warning as suggested bellow.

You're welcome. Thanks for keep commenting on it and helping with good advices.

...
> # PV = "1.0+gitr${SRCPV}"      # expands to something like 1.0+gitr3+4c1c21d7dbbf93b0df336994524313dfe0d4963b
> # PKGV = "1.0+gitr${GITPKGV}"  # expands also to something like 1.0+gitr31337+4c1c21d7dbbf93b0df336994524313dfe0d4963b

added.

...
> As we were discussing with otavio on #oe, I think there should be
> warning, that GITPKGVTAG is really sortable only if the upstream repo
> keeps consistent AND sortable tag names.
>
> For example tags in OE repo will fail, because only tested_2010-* tags
> are sortable but this sequence:
>
> tested_2010-11-04
> release-2010.12-branchpoint
> tested_2010-11-12
>
> is not. And only way to fix it when it's shiped with non-standard tag to
> targets is to bump PE :/.

Yes. I fully agree that it is something the user of the class need to
be aware of.

> Even better solution would be to set something like GITTAGFORMAT in
> recipe, to expected consistent tag scheme and if returned git describe
> prefix is different then warn builder about it or even fail or ignore
> that tag.

I like the idea but I prefer to have this merged soon so I can started
using it (for example in freerdp package) and at company.

> Proposed "warning":
>
> # or if upstream repository is always using consistent and sortable tag
> # name scheme you can get sortable version including tag name with
> # GITPKGVTAG, but be aware that ie tag sequence "v1.0, v1.2, xtest, v2.0"
> # will force you to increment PE to get upgradeable path to v2.0 revisions

I added it as a warning on the comment.

The final header is:

# gitpkgv.bbclass provides a GITPKGV and GITPKGVTAG variables to be
# used in PKGV, as described bellow:
#
# - GITPKGV which is a sortable version with the format NN+GITHASH, to
#   be used in PKGV, where
#
#   NN equals the total number of revs up to SRCREV
#   GITHASH is SRCREV's (full) hash
#
# - GITPKGVTAG which is the output of 'git describe' allowing for
#   automatic versioning
#
# gitpkgv.bbclass assumes the git repository has been cloned, and
# contains SRCREV. So ${GITPKGV} and ${GITPKGVTAG} should never be
# used in PV, only in PKGV.  It can handle SRCREV = ${AUTOREV}, as
# well as SRCREV = "<some fixed git hash>".
#
# WARNING: if upstream repository is always using consistent and
# sortable tag name scheme you can get sortable version including tag
# name with ${GITPKGVTAG}, but be aware that ie tag sequence "v1.0,
# v1.2, xtest, v2.0" will force you to increment PE to get upgradeable
# path to v2.0 revisions
#
# use example:
#
# inherit gitpkgv
#
# PV = "1.0+gitr${SRCPV}"      # expands to something like
1.0+gitr3+4c1c21d7dbbf93b0df336994524313dfe0d4963b
# PKGV = "1.0+gitr${GITPKGV}"  # expands also to something like
1.0+gitr31337+4c1c21d7d
#
# or
#
# inherit gitpkgv
#
# PV = "1.0+gitr${SRCPV}" # expands to something like
1.0+gitr3+4c1c21d7dbbf93b0df336994524313dfe0d4963b
# PKGV = "${GITPKGVTAG}"  # expands to something like 1.0-31337+g4c1c21d
#                           if there is tag v1.0 before this revision or
#                           ver1.0-31337+g4c1c21d if there is tag ver1.0

Does it seems good enough for pushing it?

-- 
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