From: Martin Jansa <martin.jansa@gmail.com>
To: Otavio Salvador <otavio@ossystems.com.br>
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: [PATCH] classes/gitpkgv.bbclass: add GITPKGVTAG that uses 'git describe'
Date: Fri, 17 Dec 2010 12:29:46 +0100 [thread overview]
Message-ID: <20101217112945.GC19482@jama> (raw)
In-Reply-To: <AANLkTi=F=kgEos0ZZb+7zefOq1G2fn5w+Wf8HqafFYsh@mail.gmail.com>
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@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@gmail.com>
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
prev parent reply other threads:[~2010-12-18 3:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-16 14:35 [PATCH] classes/gitpkgv.bbclass: add GITPKGVTAG that uses 'git describe' Otavio Salvador
2010-12-16 16:07 ` Otavio Salvador
2010-12-16 21:52 ` Martin Jansa
2010-12-17 11:00 ` Otavio Salvador
2010-12-17 11:29 ` Martin Jansa [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101217112945.GC19482@jama \
--to=martin.jansa@gmail.com \
--cc=openembedded-devel@lists.openembedded.org \
--cc=otavio@ossystems.com.br \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox