Re: Proper recipe naming and PV definition

[Darren Hart <dvhart@linux.intel.com>]

On 12/06/2010 03:24 PM, Koen Kooi wrote:
>
> Op 7 dec 2010, om 00:17 heeft Darren Hart het volgende geschreven:
>
>> I'm having trouble determining what the best practice is for naming a linux kernel recipe.
>>
>> The meta-linaro layer contains a linux-linaro recipe, and eventually I'd like it to contain two. One for the stable kernel and one for the development kernel. These are currently 2.6.35 and 2.6.37 respectively. I currently have:
>>
>> linux-linaro-2.6.35_git.bb
>> PV=2.6.35
>>
>> This results in directory names in the build tree like:
>> linux-linaro-2.6.36_2.6.35 (or similar, with the version duplicated). As I understand it, the PV _must_ contain a standard Linux kernel version along the lines of 2.6.[0-9]+-* (and parsing fails without it).
>>
>> In order to both track the version and distinguish between stable and dev, would something like the following be appropriate? This also replaces _git with _KERNELVER (as proposed by Marcin).
>>
>> linux-linaro-stable_2.6.35.bb
>> PV=2.6.35+git${SRCREV}
>>
>> linux-linaro-dev_2.6.37.bb
>> PV=2.6.37+git${SRCREV}
>
> using that will break upgrade paths since git revisions aren't monotonically increasing. I use something like this:
>
> PV = "2.6.36+2.6.37-rc4"
> PR = "r3"
> PR_append = "+gitr${SRCREV}"
> SRCREV = "a04fd22204b13ce34a3f8a8157f83c44d64f8da9"
>
> And increase PR manually everytime SRCREV changes.
>

Hrm, this mostly just raises more questions for me !

There are 5 ways to specify versions that I can see here:

recipe-name_VERSION.bb
PV
PR
PR_append

I have been looking at these as follows:

recipe-name_VERSION.bb
This is a high level version that aids users in identifying this package 
over another one with a similar name but of a different version.

PV
Package version
I think of this as a specific source version. For instance, the package 
VERSION might be 2.6.33 in the bb filename, but the PV might be 2.6.33.7.

PR
Package revision
I think of PR as specific to the recipe. If I change the do_install(){}
function for instance, I would bump this revision. It would also change 
if the PV (and thus the SRC_URI) changed (back to r0). But it primarily 
indicates a change in the recipe itself, and triggers a rebuild even if 
the underlying sources didn't change.

http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html#usingpoky-changes-prbump

PR_append
I haven't used this, but from my point of view, this looks like it 
belongs in bbappend files. A way to simply append a tag to identify a 
recipe as an extension of another recipe. Perhpas a -dev for example 
which would include a bunch of developer centric kernel config settings 
that aren't necessarily appropriate in the main recipe.
linux_2.6.33-dev.bb for example might have lots of the more intrusive 
tracing settings enabled.

PE
Package epoch
This is rarely used and is a sort of super major number apparently - 
something like the 2 in the linux kernel revisions these days. A package 
version can be explicitly described from most to least significant bits as:
PN_PE.PV.PR

INC_PR
Used for "nested packages". In the dev example above the PR might be set 
to "${INC_PR}-dev I guess. I haven't used this myself.


I get most of the above from the poky-ref-manual:
http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html

But in practice there seems to be a fair amount of interpretation left 
to the author.

Thoughts?

-- 
Darren Hart
Yocto Linux Kernel