Proper recipe naming and PV definition

Proper recipe naming and PV definition

[Darren Hart]

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}

Thanks,

-- 
Darren Hart
Yocto Linux Kernel

Re: Proper recipe naming and PV definition

[Koen Kooi]

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.

regards,

Koen

Re: Proper recipe naming and PV definition

[Darren Hart]

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

Re: Proper recipe naming and PV definition

[Bruce Ashfield]

On 10-12-06 6:17 PM, Darren Hart wrote:
> 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}

For me the _git is not negotiable. It is the indication of
the source of the package. One of the main points about building
from an upstream git source is that we can bump it via the
SRCREV and leave the recipe alone.

I'm going to continue using this:

PV = "${LINUX_VERSION}+git${SRCPV}"

For the linux-yocto recipes.

Cheers,

Bruce

>
> Thanks,
>

Re: Proper recipe naming and PV definition

[Darren Hart]

On 12/06/2010 04:53 PM, Bruce Ashfield wrote:
> On 10-12-06 6:17 PM, Darren Hart wrote:
>> 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}
>
> For me the _git is not negotiable. It is the indication of
> the source of the package. One of the main points about building
> from an upstream git source is that we can bump it via the
> SRCREV and leave the recipe alone.
>
> I'm going to continue using this:
>
> PV = "${LINUX_VERSION}+git${SRCPV}"

You have SRCPV here - I believe you intended SRCREV - correct?

If so, then your PV looks the same as mine above. The place where I 
replaced the _git was in the filename of the recipe. It still isn't 
clear to me what the _VERSION part of recipe-name_VERSION.bb is meant to 
indicate or how exactly it is used. It clearly isn't the exact and 
complete version of the source, that is what PE.PV is for, and PR 
identifies the recipe version (for lack of a better description).

For linux-yocto, _git is not actually very descriptive, while 
linux-yocto_2.6.34 and linux-yocto_2.6.37 are (there are two git trees - 
so "_git" doesn't tell the user much about where the source comes from). 
Whether the backing sourcecode source is a tarball, a git tree, or 
something else entirely is, IMO, an implementation detail which is 
adequately described by the PV we have agreed on above. This is used in 
the directory name of the build and IIRC in the messages printed to the 
console and logs, so the package and it's source should remain clear.

I do appreciate the value of -stable and -dev naming which don't have to 
change just because the underlying version changed - although I can see 
the argument that being forced to change when the version changes makes 
the change obvious to all users - which can be valuable.

A few more iterations on this and I think we'll have something :-)

-- 
Darren Hart
Yocto Linux Kernel

Re: Proper recipe naming and PV definition

[Chris Larson]

On Mon, Dec 6, 2010 at 8:46 PM, Darren Hart <dvhart@linux.intel.com> wrote:
> You have SRCPV here - I believe you intended SRCREV - correct?
>
> If so, then your PV looks the same as mine above. The place where I replaced
> the _git was in the filename of the recipe. It still isn't clear to me what
> the _VERSION part of recipe-name_VERSION.bb is meant to indicate or how
> exactly it is used. It clearly isn't the exact and complete version of the
> source, that is what PE.PV is for, and PR identifies the recipe version (for
> lack of a better description).

People seem to be making this a bit more complex than it is.  The
second component of the filename, separated by _, is simply the
*default* value of PV, just as the first component is the default
value of PN, and the third component is the default value of PR.
Naturally the 2nd and 3rd are optional, and of course you can always
override them in the recipe, it's just the default.

You can see the definitions of the PN, PV, and PR variables in
bitbake.conf -- they run a function which just splits the filename.
If those defaults were not set there, then PN, PV, and PR would always
have to be explicitly set.  It's just a convenience, that's all.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: Proper recipe naming and PV definition

[Bruce Ashfield]

On Mon, Dec 6, 2010 at 11:02 PM, Chris Larson <clarson@kergoth.com> wrote:
> On Mon, Dec 6, 2010 at 8:46 PM, Darren Hart <dvhart@linux.intel.com> wrote:
>> You have SRCPV here - I believe you intended SRCREV - correct?
>>
>> If so, then your PV looks the same as mine above. The place where I replaced
>> the _git was in the filename of the recipe. It still isn't clear to me what
>> the _VERSION part of recipe-name_VERSION.bb is meant to indicate or how
>> exactly it is used. It clearly isn't the exact and complete version of the
>> source, that is what PE.PV is for, and PR identifies the recipe version (for
>> lack of a better description).
>
> People seem to be making this a bit more complex than it is.  The
> second component of the filename, separated by _, is simply the
> *default* value of PV, just as the first component is the default
> value of PN, and the third component is the default value of PR.
> Naturally the 2nd and 3rd are optional, and of course you can always
> override them in the recipe, it's just the default.

Yep, and that's why I was keeping just the one, since I always
preferred setting the values in the recipe itself. I recall reading
this somewhere about 10 months ago, but can't find the reference
now. Thanks for the explanation!

>
> You can see the definitions of the PN, PV, and PR variables in
> bitbake.conf -- they run a function which just splits the filename.
> If those defaults were not set there, then PN, PV, and PR would always
> have to be explicitly set.  It's just a convenience, that's all.

Agreed and thanks,

Bruce

> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: Proper recipe naming and PV definition

[Bruce Ashfield]

On Mon, Dec 6, 2010 at 10:46 PM, Darren Hart <dvhart@linux.intel.com> wrote:
> On 12/06/2010 04:53 PM, Bruce Ashfield wrote:
>>
>> On 10-12-06 6:17 PM, Darren Hart wrote:
>>>
>>> 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}
>>
>> For me the _git is not negotiable. It is the indication of
>> the source of the package. One of the main points about building
>> from an upstream git source is that we can bump it via the
>> SRCREV and leave the recipe alone.
>>
>> I'm going to continue using this:
>>
>> PV = "${LINUX_VERSION}+git${SRCPV}"
>
> You have SRCPV here - I believe you intended SRCREV - correct?
>

Nope. Have a look at the recipe on your disk .. SRCPV.

> If so, then your PV looks the same as mine above. The place where I replaced
> the _git was in the filename of the recipe. It still isn't clear to me what
> the _VERSION part of recipe-name_VERSION.bb is meant to indicate or how
> exactly it is used. It clearly isn't the exact and complete version of the
> source, that is what PE.PV is for, and PR identifies the recipe version (for
> lack of a better description).
>
> For linux-yocto, _git is not actually very descriptive, while
> linux-yocto_2.6.34 and linux-yocto_2.6.37 are (there are two git trees - so
> "_git" doesn't tell the user much about where the source comes from).
> Whether the backing sourcecode source is a tarball, a git tree, or something
> else entirely is, IMO, an implementation detail which is adequately
> described by the PV we have agreed on above. This is used in the directory
> name of the build and IIRC in the messages printed to the console and logs,
> so the package and it's source should remain clear.

Quite simply, I don't want to have to juggle these constantly. And having
no version in the recipe allows me to easily EOL kernel trees and we can
control the support cost. Hence why for now, I'm not putting versions in
those recipe names.

Cheers,

Bruce

>
> I do appreciate the value of -stable and -dev naming which don't have to
> change just because the underlying version changed - although I can see the
> argument that being forced to change when the version changes makes the
> change obvious to all users - which can be valuable.
>
> A few more iterations on this and I think we'll have something :-)
>
> --
> Darren Hart
> Yocto Linux Kernel
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"