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

Martin Jansa martin.jansa at gmail.com
Fri Dec 17 11:29:46 UTC 2010


On Fri, Dec 17, 2010 at 09:00:41AM -0200, Otavio Salvador wrote:
> 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?

Yes

Acked-by: Martin Jansa <Martin.Jansa at gmail.com>

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com




More information about the Openembedded-devel mailing list