On Fri, Dec 17, 2010 at 09:00:41AM -0200, Otavio Salvador wrote: > On Thu, Dec 16, 2010 at 19:52, Martin Jansa <[email protected]> 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 <[email protected]> -- Martin 'JaMa' Jansa jabber: [email protected] _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
