[OE-core] what is the significance of the numeric version part of 'PV = "1.0.1+git${SRCPV}"'?

Mon Feb 13 16:38:42 UTC 2017

On Mon, Feb 13, 2017 at 6:51 AM, Robert P. J. Day <rpjday at crashcourse.ca>
wrote:

> On Thu, 9 Feb 2017, Leonardo Sandoval wrote:
>
> >
> >
> > On 02/09/2017 06:06 AM, Robert P. J. Day wrote:
> > >    i *thought* i understood this, but a colleague insists i don't so
> > > ... dumb question time.
> > >
> > >    recently, i asked about the netdata recipe file "netdata_git.bb",
> > > which contains the snippet:
> > >
> > >    SRC_URI = "git://github.com/firehol/netdata.git;protocol=https"
> > >    SRCREV = "36c1304e37094174ea51001903058e65053107ca"
> > >    PV = "1.0.1+git${SRCPV}"
> > >
> > > perhaps i've been wrong all this time, but i understood the above to
> > > mean that the source checked out would be based on commit
> > > 36c1304e37094174ea51001903058e65053107ca, and that the "1.0.1+" part
> > > of the PV variable was simply for aesthetics.
> > >
> > >    i realize that the full value of PV would be used to generate the
> > > final rpm files, and here's what i get:
> > >
> > >    netdata-1.0.1+git0+36c1304e37-r0.0.ppc7400.rpm
> > >    netdata-dbg-1.0.1+git0+36c1304e37-r0.0.ppc7400.rpm
> > >    netdata-dev-1.0.1+git0+36c1304e37-r0.0.ppc7400.rpm
> > >
> > > but is there some other significance or functionality associated
> > > with that "1.0.1+" prefix for PV?
> > that is the version and it should be the most recent release or tag
> > point of the SCM.
> > >
> > >    the only thing i can think of is OE's algorithm for selecting
> > > the most recent recipe. AIUI, if i have multiple versions for the
> > > same recipe. all things being equal, OE would choose the "git"
> > > recipe file over a numerically-versioned recipe file, correct?
> > >
> > >    so, say i have two recipe files:
> > >
> > >    netdata_1.0.2.bb
> > >    netdata_git.bb
> > >
> > > i assume that OE would choose the second one by default, even if,
> > > internally, that "git" form of the recipe selected a SRCREV that
> > > might represent an earlier commit than the 1.0.2 version.
> > On this area, check this link
> >
> > http://www.yoctoproject.org/docs/2.2/ref-manual/ref-
> manual.html#var-PREFERRED_VERSION
> >
> > If you want to use git recipe, then you need to explicitly indicate
> > it through the latter variable, otherwise the 1.0.2 will be used.
>
>   ok, i've never dug into the recipe versioning really, really deeply
> so a few questions if i may. (and if all this is written out
> somewhere already, a link would be just ducky.)
>
>   first, where is the code that handles recipe versioning and
> selection? i'm assuming it's part of the bitbake fetcher library, but
> i'm willing to be corrected.
>
>   next (ignoring "git"-based recipes for the moment and
> PREFERRED_VERSION aside), is the selection of one of a number of
> recipes based on the final value of "PV" that is set/calculated for a
> given recipe file? i can see that one can set "PV" in any recipe file,
> and i'm also assuming that if one doesn't do that, the value of "PV"
> would be extracted from the recipe file name so, for instance, the
> recipe file busybox_1.24.1.bb would automatically generate a "PV"
> value of 1.24.1. that part seems fairly obvious.
>

It’s the default value of PV in meta/conf/bitbake.conf, which uses inline
python to extract the version number from the filename. Not special, not
magic, just a default value for the variable.

>   next (and what might be a silly question), based on the above, is it
> possible to set absurdly misleading PV values in recipe files for the
> same recipe, such as:
>
>   rday_1.0.bb
>         PV = "2.0"
>
>   rday_2.0.bb
>         PV = "1.0"
>
> of course the above is wildly confusing, but is it legal? and given
> what's written above, i'm concluding that the most "recent" recipe
> selected by default would be "rday_1.0.bb", yes?
>

It’s legal, and the default lacking any specified preference would be the
higher PV, 2.0, which is the rday_2.0.bb recipe. Default version selection
when nothing is preferred (and no layer priorities are involved in the
selection) goes based on PV, not the filename.

  now, on to "git" recipes. for all of the git-based recipes i can
> see, the recipe files contain some variation of:
>
>   SRCREV = "8f33f80100096f7790c7b819ce37a3ed8ce8b5fa"
>   PV = "2.99.917+git${SRCPV}"
>
> (side question: is there any "git"-based recipe that *doesn't* have
> some form of the above? would a file like that be considered an error?
> or at least badly written?)
>
>   as for "git" recipe files, i've always understood that, regardless
> of the version number prefix used in setting "PV" (in the above,
> "2.99.917"), the "SRCPV" value defines the actual commit that will be
> fetched and checked out. so where does that leave the version number
> prefix "2.99.917".
>
>   as i've read it all this time, even when using a git-based recipe,
> developers like to choose that version number prefix to represent some
> official tag that was not so far in the recent past from the git
> commit ID -- kind of an aesthetic reminder that, "this git recipe
> represents some level of improvement over version 2.99.917", but not
> as far as the *next* official version number, something like that.
>

Its purpose isn’t an aesthetic reminder, it’s to ensure that
2.99.917+gitsomething is seen as newer than the 2.99.917 release version
for package upgrades.

  in addition, though, that numeric version prefix is used to select
> the most "recent" recipe version, so that (if i read this correctly),
> if i have two recipe files:
>
>   * netdata_1.0.2.bb
>   * netdata_git.bb
>
> while the first file is a fixed version, it all depends on the value
> of "PV" set in the second version, so that if the second recipe file
> contained the line:
>
>   PV = "1.0.1+git${SRCPV}"
>
> then PREFERRED_VERSION aside, the fixed version (1.0.2) would be
> selected as the more recent recipe file, even if that git SRCPV
> represented newer content. how am i doing so far?
>

That’s correct, but remember that DEFAULT_PREFERENCE is always a factor,
most often when there’s both a release recipe and a git recipe, the git
recipe will have a -1 default preference. That said, nowadays we shouldn’t
have multiple versions in a layer anyway.
-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170213/ac5c405a/attachment-0002.html>