[PATCH] containerd: Remove leading "v" from PV

[PATCH] containerd: Remove leading "v" from PV

[Peter Kjellerstedt]

The leading "v" in the version otherwise makes its way into, e.g., the
SBOM.

Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
---

There are another 30 recipes in meta-virtualization that have a leading
"v" in their versions, but this is the only one of them that we use.
I can send patches for the others as well if you want.

 recipes-containers/containerd/containerd_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-containers/containerd/containerd_git.bb b/recipes-containers/containerd/containerd_git.bb
index bae86146..c46d1673 100644
--- a/recipes-containers/containerd/containerd_git.bb
+++ b/recipes-containers/containerd/containerd_git.bb
@@ -16,7 +16,7 @@ SRC_URI = "git://github.com/containerd/containerd;branch=release/2.1;protocol=ht
 LICENSE = "Apache-2.0"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=1269f40c0d099c21a871163984590d89"
 
-CONTAINERD_VERSION = "v2.1.4"
+CONTAINERD_VERSION = "2.1.4"
 
 # EXTRA_OEMAKE += "GODEBUG=1"
 

Re: [meta-virtualization] [PATCH] containerd: Remove leading "v" from PV

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 1930 bytes --]

On Sun, Sep 7, 2025 at 6:59 AM Peter Kjellerstedt via lists.yoctoproject.org
<peter.kjellerstedt=axis.com@lists.yoctoproject.org> wrote:

> The leading "v" in the version otherwise makes its way into, e.g., the
> SBOM.
>
> Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> ---
>
> There are another 30 recipes in meta-virtualization that have a leading
> "v" in their versions, but this is the only one of them that we use.
> I can send patches for the others as well if you want.
>

No thanks, to any of them.

The "v" isn't by mistake. I don't see any reason to remove it.

Bruce



>
>  recipes-containers/containerd/containerd_git.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/recipes-containers/containerd/containerd_git.bb
> b/recipes-containers/containerd/containerd_git.bb
> index bae86146..c46d1673 100644
> --- a/recipes-containers/containerd/containerd_git.bb
> +++ b/recipes-containers/containerd/containerd_git.bb
> @@ -16,7 +16,7 @@ SRC_URI = "git://
> github.com/containerd/containerd;branch=release/2.1;protocol=ht
>  LICENSE = "Apache-2.0"
>  LIC_FILES_CHKSUM = "file://LICENSE;md5=1269f40c0d099c21a871163984590d89"
>
> -CONTAINERD_VERSION = "v2.1.4"
> +CONTAINERD_VERSION = "2.1.4"
>
>  # EXTRA_OEMAKE += "GODEBUG=1"
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#9377):
> https://lists.yoctoproject.org/g/meta-virtualization/message/9377
> Mute This Topic: https://lists.yoctoproject.org/mt/115111597/1050810
> Group Owner: meta-virtualization+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub [
> bruce.ashfield@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II

[-- Attachment #2: Type: text/html, Size: 4142 bytes --]

Re: [meta-virtualization] [PATCH] containerd: Remove leading "v" from PV

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 2415 bytes --]

On Sun, Sep 7, 2025 at 4:17 PM Bruce Ashfield <bruce.ashfield@gmail.com>
wrote:

>
>
> On Sun, Sep 7, 2025 at 6:59 AM Peter Kjellerstedt via
> lists.yoctoproject.org <peter.kjellerstedt=axis.com@lists.yoctoproject.org>
> wrote:
>
>> The leading "v" in the version otherwise makes its way into, e.g., the
>> SBOM.
>>
>> Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
>> ---
>>
>> There are another 30 recipes in meta-virtualization that have a leading
>> "v" in their versions, but this is the only one of them that we use.
>> I can send patches for the others as well if you want.
>>
>
> No thanks, to any of them.
>
> The "v" isn't by mistake. I don't see any reason to remove it.
>

What I mean by this, is that someone needs to tell me why SBOM
is broken enough that it can't handle the "v", and what problems it
causes in the SBOM.

Bruce



>
> Bruce
>
>
>
>>
>>  recipes-containers/containerd/containerd_git.bb | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/recipes-containers/containerd/containerd_git.bb
>> b/recipes-containers/containerd/containerd_git.bb
>> index bae86146..c46d1673 100644
>> --- a/recipes-containers/containerd/containerd_git.bb
>> +++ b/recipes-containers/containerd/containerd_git.bb
>> @@ -16,7 +16,7 @@ SRC_URI = "git://
>> github.com/containerd/containerd;branch=release/2.1;protocol=ht
>>  LICENSE = "Apache-2.0"
>>  LIC_FILES_CHKSUM = "file://LICENSE;md5=1269f40c0d099c21a871163984590d89"
>>
>> -CONTAINERD_VERSION = "v2.1.4"
>> +CONTAINERD_VERSION = "2.1.4"
>>
>>  # EXTRA_OEMAKE += "GODEBUG=1"
>>
>>
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> View/Reply Online (#9377):
>> https://lists.yoctoproject.org/g/meta-virtualization/message/9377
>> Mute This Topic: https://lists.yoctoproject.org/mt/115111597/1050810
>> Group Owner: meta-virtualization+owner@lists.yoctoproject.org
>> Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub [
>> bruce.ashfield@gmail.com]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>
>>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await thee
> at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
>

-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II

[-- Attachment #2: Type: text/html, Size: 5481 bytes --]

Re: [meta-virtualization] [PATCH] containerd: Remove leading "v" from PV

[Mikko Rapeli]

Hi,

On Sun, Sep 07, 2025 at 04:19:17PM -0400, Bruce Ashfield via lists.yoctoproject.org wrote:
> On Sun, Sep 7, 2025 at 4:17 PM Bruce Ashfield <bruce.ashfield@gmail.com>
> wrote:
> > On Sun, Sep 7, 2025 at 6:59 AM Peter Kjellerstedt via
> > lists.yoctoproject.org <peter.kjellerstedt=axis.com@lists.yoctoproject.org>
> > wrote:
> >
> >> The leading "v" in the version otherwise makes its way into, e.g., the
> >> SBOM.
> >>
> >> Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> >> ---
> >>
> >> There are another 30 recipes in meta-virtualization that have a leading
> >> "v" in their versions, but this is the only one of them that we use.
> >> I can send patches for the others as well if you want.
> >>
> >
> > No thanks, to any of them.
> >
> > The "v" isn't by mistake. I don't see any reason to remove it.
> >
> 
> What I mean by this, is that someone needs to tell me why SBOM
> is broken enough that it can't handle the "v", and what problems it
> causes in the SBOM.

At least CVE checking tooling can compare PV against version numbers
outside of yocto build environment which are often without
"v" prefix used by several projects in git tags. Same for the SW versions
reported by the tools in logs and/or command line.

I think the tools can handle "v" but different ways of reporting version
numbers break usecases if "v" is not used in all contexts like in CVE
reporting.

For example Debian doesn't report containerd versions with leading "v".

Cheers,

-Mikko

Re: [meta-virtualization] [PATCH] containerd: Remove leading "v" from PV

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 3038 bytes --]

On Mon, Sep 8, 2025 at 3:16 AM Mikko Rapeli <mikko.rapeli@linaro.org> wrote:

> Hi,
>
> On Sun, Sep 07, 2025 at 04:19:17PM -0400, Bruce Ashfield via
> lists.yoctoproject.org wrote:
> > On Sun, Sep 7, 2025 at 4:17 PM Bruce Ashfield <bruce.ashfield@gmail.com>
> > wrote:
> > > On Sun, Sep 7, 2025 at 6:59 AM Peter Kjellerstedt via
> > > lists.yoctoproject.org <peter.kjellerstedt=
> axis.com@lists.yoctoproject.org>
> > > wrote:
> > >
> > >> The leading "v" in the version otherwise makes its way into, e.g., the
> > >> SBOM.
> > >>
> > >> Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> > >> ---
> > >>
> > >> There are another 30 recipes in meta-virtualization that have a
> leading
> > >> "v" in their versions, but this is the only one of them that we use.
> > >> I can send patches for the others as well if you want.
> > >>
> > >
> > > No thanks, to any of them.
> > >
> > > The "v" isn't by mistake. I don't see any reason to remove it.
> > >
> >
> > What I mean by this, is that someone needs to tell me why SBOM
> > is broken enough that it can't handle the "v", and what problems it
> > causes in the SBOM.
>
> At least CVE checking tooling can compare PV against version numbers
> outside of yocto build environment which are often without
> "v" prefix used by several projects in git tags. Same for the SW versions
> reported by the tools in logs and/or command line.
>
> I think the tools can handle "v" but different ways of reporting version
> numbers break usecases if "v" is not used in all contexts like in CVE
> reporting.
>
> For example Debian doesn't report containerd versions with leading "v".
>
That's along the lines of what I thought. (I mean, in the end I doesn't
matter how other distros and build systems have their versions, that
is their choice and why we have the CVE version variable).

If someone sends me a specific example of breakage (a tool and output),
then I'd definitely be interested in seeing that. So that I can follow up
on it in a bit more detail.

The policy I have, and have always had (when possible, mistakes
happen) is that PV matches the tag format of the repository. So in
most of the projects that means "v". There's other tooling and processes
that are looking to do that matching and have been around for a while.

As long as the version doesn't obviously break semver, I've always
just left it alone (and all the sever bits I've suffered say that the
decorations don't make it incompatible..

Fundamentally I don't worry about merging cosmetic changes, and
when potentially new tools come along and ask the input formats
and source to be changed, that's a problem for me .. since compatibility
is nice, but so is consistency and backwards compatibility.

Thanks for the follow up. Definitely helpful.

Bruce


>
> Cheers,
>
> -Mikko
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II

[-- Attachment #2: Type: text/html, Size: 5890 bytes --]

RE: [meta-virtualization] [PATCH] containerd: Remove leading "v" from PV

[Peter Kjellerstedt]

[-- Attachment #1: Type: text/plain, Size: 4488 bytes --]

Well, from my point of view, the recipes in meta-virtualization that set PV = "v…" differs from all other recipes in Poky, OpenEmbedded, etc where no recipes set a PV in that way, but rather all of them set PV to only the numeric version (possibly followed by +git) even if the Git tag in many cases contains a leading v. Typically this is done by setting the version in the recipe name, but even when PV is set explicitly, it is done without the leading v.

Now, the problem for me is that I want consistency, and since all other packages that are listed in our SBOM have versions without a leading v, I of course want this to apply to the containerd package as well. This is of course easily fixed via a bbappend (which is what we are currently doing). The drawback is that since the containerd recipe file is not versioned, I cannot have a versioned bbappend and thus I will not get a build failure when the recipe is updated to a new version, and we risk having PV set to something that does not match SRCREV. :(

//Peter

From: Bruce Ashfield <bruce.ashfield@gmail.com>
Sent: den 8 september 2025 14:52
To: Mikko Rapeli <mikko.rapeli@linaro.org>
Cc: Peter Kjellerstedt <peter.kjellerstedt@axis.com>; meta-virtualization@lists.yoctoproject.org
Subject: Re: [meta-virtualization] [PATCH] containerd: Remove leading "v" from PV



On Mon, Sep 8, 2025 at 3:16 AM Mikko Rapeli <mikko.rapeli@linaro.org<mailto:mikko.rapeli@linaro.org>> wrote:
Hi,

On Sun, Sep 07, 2025 at 04:19:17PM -0400, Bruce Ashfield via lists.yoctoproject.org<http://lists.yoctoproject.org> wrote:
> On Sun, Sep 7, 2025 at 4:17 PM Bruce Ashfield <bruce.ashfield@gmail.com<mailto:bruce.ashfield@gmail.com>>
> wrote:
> > On Sun, Sep 7, 2025 at 6:59 AM Peter Kjellerstedt via
> > lists.yoctoproject.org<http://lists.yoctoproject.org> <peter.kjellerstedt=axis.com@lists.yoctoproject.org<mailto:axis.com@lists.yoctoproject.org>>
> > wrote:
> >
> >> The leading "v" in the version otherwise makes its way into, e.g., the
> >> SBOM.
> >>
> >> Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com<mailto:peter.kjellerstedt@axis.com>>
> >> ---
> >>
> >> There are another 30 recipes in meta-virtualization that have a leading
> >> "v" in their versions, but this is the only one of them that we use.
> >> I can send patches for the others as well if you want.
> >>
> >
> > No thanks, to any of them.
> >
> > The "v" isn't by mistake. I don't see any reason to remove it.
> >
>
> What I mean by this, is that someone needs to tell me why SBOM
> is broken enough that it can't handle the "v", and what problems it
> causes in the SBOM.

At least CVE checking tooling can compare PV against version numbers
outside of yocto build environment which are often without
"v" prefix used by several projects in git tags. Same for the SW versions
reported by the tools in logs and/or command line.

I think the tools can handle "v" but different ways of reporting version
numbers break usecases if "v" is not used in all contexts like in CVE
reporting.

For example Debian doesn't report containerd versions with leading "v".
That's along the lines of what I thought. (I mean, in the end I doesn't
matter how other distros and build systems have their versions, that
is their choice and why we have the CVE version variable).

If someone sends me a specific example of breakage (a tool and output),
then I'd definitely be interested in seeing that. So that I can follow up
on it in a bit more detail.

The policy I have, and have always had (when possible, mistakes
happen) is that PV matches the tag format of the repository. So in
most of the projects that means "v". There's other tooling and processes
that are looking to do that matching and have been around for a while.

As long as the version doesn't obviously break semver, I've always
just left it alone (and all the sever bits I've suffered say that the
decorations don't make it incompatible..

Fundamentally I don't worry about merging cosmetic changes, and
when potentially new tools come along and ask the input formats
and source to be changed, that's a problem for me .. since compatibility
is nice, but so is consistency and backwards compatibility.

Thanks for the follow up. Definitely helpful.

Bruce


Cheers,

-Mikko


--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

[-- Attachment #2: Type: text/html, Size: 12620 bytes --]

Re: [meta-virtualization] [PATCH] containerd: Remove leading "v" from PV

[Koen Kooi]

> Op 8 sep 2025, om 14:52 heeft Bruce Ashfield via lists.yoctoproject.org <bruce.ashfield=gmail.com@lists.yoctoproject.org> het volgende geschreven:
> 
> [...]
> The policy I have, and have always had (when possible, mistakes
> happen) is that PV matches the tag format of the repository. So in
> most of the projects that means "v". [...]

I've noticed that projects that use 'v2.1.4' as a tag won't use the 'v' in release notes, documentation and announcements. For containerd specifically:

* Tag notice: https://github.com/containerd/containerd/releases/tag/v2.1.4 <- has 'v'
* Tag title "containerd 2.1.4" <- lacks 'v'
* Release note text "Welcome to the v2.1.4 release of containerd!" <- 'v'!, followed by 'The fourth patch release for containerd 2.1 contains various fixes and updates', which has no 'v'!
* Downloads list: https://containerd.io/downloads/, the tarball itself lacks the v, the list lacks the v, but the release folder does have the v. 

So containerd, at the high levels, doesn't use the v, but the closer you get to the code, the more it will leak through. Personally, I'd go for PV="2.1.4", and ;tag=v${PV} in this case.

regards,

Koen

Re: [meta-virtualization] [PATCH] containerd: Remove leading "v" from PV

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 5007 bytes --]

On Mon, Sep 8, 2025 at 11:15 AM Peter Kjellerstedt <
peter.kjellerstedt@axis.com> wrote:

> Well, from my point of view, the recipes in meta-virtualization that set PV
> = "v…" differs from all other recipes in Poky, OpenEmbedded, etc where no
> recipes set a PV in that way, but rather all of them set PV to only the
> numeric version (possibly followed by +git) even if the Git tag in many
> cases contains a leading v. Typically this is done by setting the version
> in the recipe name, but even when PV is set explicitly, it is done
> without the leading v.
>
>
>
> Now, the problem for me is that I want consistency, and since all other
> packages that are listed in our SBOM have versions without a leading v, I
> of course want this to apply to the containerd package as well. This is
> of course easily fixed via a bbappend (which is what we are currently
> doing). The drawback is that since the containerd recipe file is not
> versioned, I cannot have a versioned bbappend and thus I will not get a
> build failure when the recipe is updated to a new version, and we risk
> having PV set to something that does not match SRCREV. :(
>
>
>

And what would you say to the users that want and expect the leading  "v",
since it has always been there ?

Bruce



> //Peter
>
>
>
> *From:* Bruce Ashfield <bruce.ashfield@gmail.com>
> *Sent:* den 8 september 2025 14:52
> *To:* Mikko Rapeli <mikko.rapeli@linaro.org>
> *Cc:* Peter Kjellerstedt <peter.kjellerstedt@axis.com>;
> meta-virtualization@lists.yoctoproject.org
> *Subject:* Re: [meta-virtualization] [PATCH] containerd: Remove leading
> "v" from PV
>
>
>
>
>
>
>
> On Mon, Sep 8, 2025 at 3:16 AM Mikko Rapeli <mikko.rapeli@linaro.org>
> wrote:
>
> Hi,
>
> On Sun, Sep 07, 2025 at 04:19:17PM -0400, Bruce Ashfield via
> lists.yoctoproject.org wrote:
> > On Sun, Sep 7, 2025 at 4:17 PM Bruce Ashfield <bruce.ashfield@gmail.com>
> > wrote:
> > > On Sun, Sep 7, 2025 at 6:59 AM Peter Kjellerstedt via
> > > lists.yoctoproject.org <peter.kjellerstedt=
> axis.com@lists.yoctoproject.org>
> > > wrote:
> > >
> > >> The leading "v" in the version otherwise makes its way into, e.g., the
> > >> SBOM.
> > >>
> > >> Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> > >> ---
> > >>
> > >> There are another 30 recipes in meta-virtualization that have a
> leading
> > >> "v" in their versions, but this is the only one of them that we use.
> > >> I can send patches for the others as well if you want.
> > >>
> > >
> > > No thanks, to any of them.
> > >
> > > The "v" isn't by mistake. I don't see any reason to remove it.
> > >
> >
> > What I mean by this, is that someone needs to tell me why SBOM
> > is broken enough that it can't handle the "v", and what problems it
> > causes in the SBOM.
>
> At least CVE checking tooling can compare PV against version numbers
> outside of yocto build environment which are often without
> "v" prefix used by several projects in git tags. Same for the SW versions
> reported by the tools in logs and/or command line.
>
> I think the tools can handle "v" but different ways of reporting version
> numbers break usecases if "v" is not used in all contexts like in CVE
> reporting.
>
> For example Debian doesn't report containerd versions with leading "v".
>
> That's along the lines of what I thought. (I mean, in the end I doesn't
>
> matter how other distros and build systems have their versions, that
>
> is their choice and why we have the CVE version variable).
>
>
>
> If someone sends me a specific example of breakage (a tool and output),
>
> then I'd definitely be interested in seeing that. So that I can follow up
>
> on it in a bit more detail.
>
>
>
> The policy I have, and have always had (when possible, mistakes
>
> happen) is that PV matches the tag format of the repository. So in
>
> most of the projects that means "v". There's other tooling and processes
>
> that are looking to do that matching and have been around for a while.
>
>
>
> As long as the version doesn't obviously break semver, I've always
>
> just left it alone (and all the sever bits I've suffered say that the
>
> decorations don't make it incompatible..
>
>
>
> Fundamentally I don't worry about merging cosmetic changes, and
>
> when potentially new tools come along and ask the input formats
>
> and source to be changed, that's a problem for me .. since compatibility
>
> is nice, but so is consistency and backwards compatibility.
>
>
>
> Thanks for the follow up. Definitely helpful.
>
>
>
> Bruce
>
>
>
>
> Cheers,
>
> -Mikko
>
>
>
>
> --
>
> - Thou shalt not follow the NULL pointer, for chaos and madness await thee
> at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II

[-- Attachment #2: Type: text/html, Size: 12510 bytes --]

RE: [meta-virtualization] [PATCH] containerd: Remove leading "v" from PV

[Peter Kjellerstedt]

[-- Attachment #1: Type: text/plain, Size: 5625 bytes --]

“Sorry, the leading v was a mistake.” But seriously, I get what you are saying. Keeping the leading v is of course also a form of consistency. Even though I personally would prefer the consistency in what is being generated rather than what has always been.

//Peter

From: Bruce Ashfield <bruce.ashfield@gmail.com>
Sent: den 8 september 2025 17:25
To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Cc: Mikko Rapeli <mikko.rapeli@linaro.org>; meta-virtualization@lists.yoctoproject.org
Subject: Re: [meta-virtualization] [PATCH] containerd: Remove leading "v" from PV



On Mon, Sep 8, 2025 at 11:15 AM Peter Kjellerstedt <peter.kjellerstedt@axis.com<mailto:peter.kjellerstedt@axis.com>> wrote:
Well, from my point of view, the recipes in meta-virtualization that set PV = "v…" differs from all other recipes in Poky, OpenEmbedded, etc where no recipes set a PV in that way, but rather all of them set PV to only the numeric version (possibly followed by +git) even if the Git tag in many cases contains a leading v. Typically this is done by setting the version in the recipe name, but even when PV is set explicitly, it is done without the leading v.

Now, the problem for me is that I want consistency, and since all other packages that are listed in our SBOM have versions without a leading v, I of course want this to apply to the containerd package as well. This is of course easily fixed via a bbappend (which is what we are currently doing). The drawback is that since the containerd recipe file is not versioned, I cannot have a versioned bbappend and thus I will not get a build failure when the recipe is updated to a new version, and we risk having PV set to something that does not match SRCREV. :(


And what would you say to the users that want and expect the leading  "v", since it has always been there ?

Bruce


//Peter

From: Bruce Ashfield <bruce.ashfield@gmail.com<mailto:bruce.ashfield@gmail.com>>
Sent: den 8 september 2025 14:52
To: Mikko Rapeli <mikko.rapeli@linaro.org<mailto:mikko.rapeli@linaro.org>>
Cc: Peter Kjellerstedt <peter.kjellerstedt@axis.com<mailto:peter.kjellerstedt@axis.com>>; meta-virtualization@lists.yoctoproject.org<mailto:meta-virtualization@lists.yoctoproject.org>
Subject: Re: [meta-virtualization] [PATCH] containerd: Remove leading "v" from PV



On Mon, Sep 8, 2025 at 3:16 AM Mikko Rapeli <mikko.rapeli@linaro.org<mailto:mikko.rapeli@linaro.org>> wrote:
Hi,

On Sun, Sep 07, 2025 at 04:19:17PM -0400, Bruce Ashfield via lists.yoctoproject.org<http://lists.yoctoproject.org> wrote:
> On Sun, Sep 7, 2025 at 4:17 PM Bruce Ashfield <bruce.ashfield@gmail.com<mailto:bruce.ashfield@gmail.com>>
> wrote:
> > On Sun, Sep 7, 2025 at 6:59 AM Peter Kjellerstedt via
> > lists.yoctoproject.org<http://lists.yoctoproject.org> <peter.kjellerstedt=axis.com@lists.yoctoproject.org<mailto:axis.com@lists.yoctoproject.org>>
> > wrote:
> >
> >> The leading "v" in the version otherwise makes its way into, e.g., the
> >> SBOM.
> >>
> >> Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com<mailto:peter.kjellerstedt@axis.com>>
> >> ---
> >>
> >> There are another 30 recipes in meta-virtualization that have a leading
> >> "v" in their versions, but this is the only one of them that we use.
> >> I can send patches for the others as well if you want.
> >>
> >
> > No thanks, to any of them.
> >
> > The "v" isn't by mistake. I don't see any reason to remove it.
> >
>
> What I mean by this, is that someone needs to tell me why SBOM
> is broken enough that it can't handle the "v", and what problems it
> causes in the SBOM.

At least CVE checking tooling can compare PV against version numbers
outside of yocto build environment which are often without
"v" prefix used by several projects in git tags. Same for the SW versions
reported by the tools in logs and/or command line.

I think the tools can handle "v" but different ways of reporting version
numbers break usecases if "v" is not used in all contexts like in CVE
reporting.

For example Debian doesn't report containerd versions with leading "v".
That's along the lines of what I thought. (I mean, in the end I doesn't
matter how other distros and build systems have their versions, that
is their choice and why we have the CVE version variable).

If someone sends me a specific example of breakage (a tool and output),
then I'd definitely be interested in seeing that. So that I can follow up
on it in a bit more detail.

The policy I have, and have always had (when possible, mistakes
happen) is that PV matches the tag format of the repository. So in
most of the projects that means "v". There's other tooling and processes
that are looking to do that matching and have been around for a while.

As long as the version doesn't obviously break semver, I've always
just left it alone (and all the sever bits I've suffered say that the
decorations don't make it incompatible..

Fundamentally I don't worry about merging cosmetic changes, and
when potentially new tools come along and ask the input formats
and source to be changed, that's a problem for me .. since compatibility
is nice, but so is consistency and backwards compatibility.

Thanks for the follow up. Definitely helpful.

Bruce


Cheers,

-Mikko


--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

[-- Attachment #2: Type: text/html, Size: 18593 bytes --]

Re: [meta-virtualization] [PATCH] containerd: Remove leading "v" from PV

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 6090 bytes --]

:)

I also get what you are looking for.

I'll get through my M3 package updates and put some extra thought into this.

Bruce

On Mon, Sep 8, 2025 at 11:45 AM Peter Kjellerstedt <
peter.kjellerstedt@axis.com> wrote:

> “Sorry, the leading v was a mistake.” But seriously, I get what you are
> saying. Keeping the leading v is of course also a form of consistency. Even
> though I personally would prefer the consistency in what is being generated
> rather than what has always been.
>
>
>
> //Peter
>
>
>
> *From:* Bruce Ashfield <bruce.ashfield@gmail.com>
> *Sent:* den 8 september 2025 17:25
> *To:* Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> *Cc:* Mikko Rapeli <mikko.rapeli@linaro.org>;
> meta-virtualization@lists.yoctoproject.org
> *Subject:* Re: [meta-virtualization] [PATCH] containerd: Remove leading
> "v" from PV
>
>
>
>
>
>
>
> On Mon, Sep 8, 2025 at 11:15 AM Peter Kjellerstedt <
> peter.kjellerstedt@axis.com> wrote:
>
> Well, from my point of view, the recipes in meta-virtualization that set PV
> = "v…" differs from all other recipes in Poky, OpenEmbedded, etc where no
> recipes set a PV in that way, but rather all of them set PV to only the
> numeric version (possibly followed by +git) even if the Git tag in many
> cases contains a leading v. Typically this is done by setting the version
> in the recipe name, but even when PV is set explicitly, it is done
> without the leading v.
>
>
>
> Now, the problem for me is that I want consistency, and since all other
> packages that are listed in our SBOM have versions without a leading v, I
> of course want this to apply to the containerd package as well. This is
> of course easily fixed via a bbappend (which is what we are currently
> doing). The drawback is that since the containerd recipe file is not
> versioned, I cannot have a versioned bbappend and thus I will not get a
> build failure when the recipe is updated to a new version, and we risk
> having PV set to something that does not match SRCREV. :(
>
>
>
>
>
> And what would you say to the users that want and expect the leading  "v",
> since it has always been there ?
>
>
>
> Bruce
>
>
>
>
>
> //Peter
>
>
>
> *From:* Bruce Ashfield <bruce.ashfield@gmail.com>
> *Sent:* den 8 september 2025 14:52
> *To:* Mikko Rapeli <mikko.rapeli@linaro.org>
> *Cc:* Peter Kjellerstedt <peter.kjellerstedt@axis.com>;
> meta-virtualization@lists.yoctoproject.org
> *Subject:* Re: [meta-virtualization] [PATCH] containerd: Remove leading
> "v" from PV
>
>
>
>
>
>
>
> On Mon, Sep 8, 2025 at 3:16 AM Mikko Rapeli <mikko.rapeli@linaro.org>
> wrote:
>
> Hi,
>
> On Sun, Sep 07, 2025 at 04:19:17PM -0400, Bruce Ashfield via
> lists.yoctoproject.org wrote:
> > On Sun, Sep 7, 2025 at 4:17 PM Bruce Ashfield <bruce.ashfield@gmail.com>
> > wrote:
> > > On Sun, Sep 7, 2025 at 6:59 AM Peter Kjellerstedt via
> > > lists.yoctoproject.org <peter.kjellerstedt=
> axis.com@lists.yoctoproject.org>
> > > wrote:
> > >
> > >> The leading "v" in the version otherwise makes its way into, e.g., the
> > >> SBOM.
> > >>
> > >> Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> > >> ---
> > >>
> > >> There are another 30 recipes in meta-virtualization that have a
> leading
> > >> "v" in their versions, but this is the only one of them that we use.
> > >> I can send patches for the others as well if you want.
> > >>
> > >
> > > No thanks, to any of them.
> > >
> > > The "v" isn't by mistake. I don't see any reason to remove it.
> > >
> >
> > What I mean by this, is that someone needs to tell me why SBOM
> > is broken enough that it can't handle the "v", and what problems it
> > causes in the SBOM.
>
> At least CVE checking tooling can compare PV against version numbers
> outside of yocto build environment which are often without
> "v" prefix used by several projects in git tags. Same for the SW versions
> reported by the tools in logs and/or command line.
>
> I think the tools can handle "v" but different ways of reporting version
> numbers break usecases if "v" is not used in all contexts like in CVE
> reporting.
>
> For example Debian doesn't report containerd versions with leading "v".
>
> That's along the lines of what I thought. (I mean, in the end I doesn't
>
> matter how other distros and build systems have their versions, that
>
> is their choice and why we have the CVE version variable).
>
>
>
> If someone sends me a specific example of breakage (a tool and output),
>
> then I'd definitely be interested in seeing that. So that I can follow up
>
> on it in a bit more detail.
>
>
>
> The policy I have, and have always had (when possible, mistakes
>
> happen) is that PV matches the tag format of the repository. So in
>
> most of the projects that means "v". There's other tooling and processes
>
> that are looking to do that matching and have been around for a while.
>
>
>
> As long as the version doesn't obviously break semver, I've always
>
> just left it alone (and all the sever bits I've suffered say that the
>
> decorations don't make it incompatible..
>
>
>
> Fundamentally I don't worry about merging cosmetic changes, and
>
> when potentially new tools come along and ask the input formats
>
> and source to be changed, that's a problem for me .. since compatibility
>
> is nice, but so is consistency and backwards compatibility.
>
>
>
> Thanks for the follow up. Definitely helpful.
>
>
>
> Bruce
>
>
>
>
> Cheers,
>
> -Mikko
>
>
>
>
> --
>
> - Thou shalt not follow the NULL pointer, for chaos and madness await thee
> at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
>
>
>
> --
>
> - Thou shalt not follow the NULL pointer, for chaos and madness await thee
> at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II

[-- Attachment #2: Type: text/html, Size: 15739 bytes --]

Re: [meta-virtualization] [PATCH] containerd: Remove leading "v" from PV

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 7973 bytes --]

Considering I'm part of the collective, let's just say that the opening
statement is incorrect, no matter what a generative AI may or may not say.

I'm also done with this for now, I have much higher priority items that
need attention.

Bruce

On Tue, Sep 9, 2025 at 9:06 AM Rich Persaud via lists.yoctoproject.org
<persaur=gmail.com@lists.yoctoproject.org> wrote:

> If it was collectively decided that the OE recipe metadata variable PV
> should be numeric or otherwise constrained, to improve interoperability
> with other software identity ecosystems, then future bitbake and YP
> versions could document and enforce a type or syntax constraint.
>
> ChatGPT query: "How many OpenEmbedded and Yocto Project recipes have a PV
> recipe metadata variable that is non-numeric, e.g. include the letter 'v'
> in the value of the variable?"
>
> ChatGPT response excerpt:
> --
> Recipes usually define PV implicitly. Many recipes don’t explicitly
> declare the PV variable in the .bb file; BitBake derives it automatically
> from the recipe filename (e.g., foo_1.2.bb implies PV = "1.2").
>
> Variations exist. Some recipes do explicitly set PV, and those may include
> letters, plus signs (e.g., 1.2+git${SRCPV}), tildes (e.g., 0.8.16~rc1), or
> even incorporate placeholders like AUTOINC when using revisions from SCM
>
> You can compute the counts [locally] by grepping through recipe layers for
> PV assignments containing letters or symbols.
> --
>
> Rich
>
> On Sep 8, 2025, at 11:45, Peter Kjellerstedt via lists.yoctoproject.org
> <peter.kjellerstedt=axis.com@lists.yoctoproject.org> wrote:
>
> 
>
> “Sorry, the leading v was a mistake.” But seriously, I get what you are
> saying. Keeping the leading v is of course also a form of consistency. Even
> though I personally would prefer the consistency in what is being generated
> rather than what has always been.
>
>
>
> //Peter
>
>
>
> *From:* Bruce Ashfield <bruce.ashfield@gmail.com>
> *Sent:* den 8 september 2025 17:25
> *To:* Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> *Cc:* Mikko Rapeli <mikko.rapeli@linaro.org>;
> meta-virtualization@lists.yoctoproject.org
> *Subject:* Re: [meta-virtualization] [PATCH] containerd: Remove leading
> "v" from PV
>
>
>
>
>
>
>
> On Mon, Sep 8, 2025 at 11:15 AM Peter Kjellerstedt <
> peter.kjellerstedt@axis.com> wrote:
>
> Well, from my point of view, the recipes in meta-virtualization that set PV
> = "v…" differs from all other recipes in Poky, OpenEmbedded, etc where no
> recipes set a PV in that way, but rather all of them set PV to only the
> numeric version (possibly followed by +git) even if the Git tag in many
> cases contains a leading v. Typically this is done by setting the version
> in the recipe name, but even when PV is set explicitly, it is done
> without the leading v.
>
>
>
> Now, the problem for me is that I want consistency, and since all other
> packages that are listed in our SBOM have versions without a leading v, I
> of course want this to apply to the containerd package as well. This is
> of course easily fixed via a bbappend (which is what we are currently
> doing). The drawback is that since the containerd recipe file is not
> versioned, I cannot have a versioned bbappend and thus I will not get a
> build failure when the recipe is updated to a new version, and we risk
> having PV set to something that does not match SRCREV. :(
>
>
>
>
>
> And what would you say to the users that want and expect the leading  "v",
> since it has always been there ?
>
>
>
> Bruce
>
>
>
>
>
> //Peter
>
>
>
> *From:* Bruce Ashfield <bruce.ashfield@gmail.com>
> *Sent:* den 8 september 2025 14:52
> *To:* Mikko Rapeli <mikko.rapeli@linaro.org>
> *Cc:* Peter Kjellerstedt <peter.kjellerstedt@axis.com>;
> meta-virtualization@lists.yoctoproject.org
> *Subject:* Re: [meta-virtualization] [PATCH] containerd: Remove leading
> "v" from PV
>
>
>
>
>
>
>
> On Mon, Sep 8, 2025 at 3:16 AM Mikko Rapeli <mikko.rapeli@linaro.org>
> wrote:
>
> Hi,
>
> On Sun, Sep 07, 2025 at 04:19:17PM -0400, Bruce Ashfield via
> lists.yoctoproject.org wrote:
> > On Sun, Sep 7, 2025 at 4:17 PM Bruce Ashfield <bruce.ashfield@gmail.com>
> > wrote:
> > > On Sun, Sep 7, 2025 at 6:59 AM Peter Kjellerstedt via
> > > lists.yoctoproject.org <peter.kjellerstedt=
> axis.com@lists.yoctoproject.org>
> > > wrote:
> > >
> > >> The leading "v" in the version otherwise makes its way into, e.g., the
> > >> SBOM.
> > >>
> > >> Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> > >> ---
> > >>
> > >> There are another 30 recipes in meta-virtualization that have a
> leading
> > >> "v" in their versions, but this is the only one of them that we use.
> > >> I can send patches for the others as well if you want.
> > >>
> > >
> > > No thanks, to any of them.
> > >
> > > The "v" isn't by mistake. I don't see any reason to remove it.
> > >
> >
> > What I mean by this, is that someone needs to tell me why SBOM
> > is broken enough that it can't handle the "v", and what problems it
> > causes in the SBOM.
>
> At least CVE checking tooling can compare PV against version numbers
> outside of yocto build environment which are often without
> "v" prefix used by several projects in git tags. Same for the SW versions
> reported by the tools in logs and/or command line.
>
> I think the tools can handle "v" but different ways of reporting version
> numbers break usecases if "v" is not used in all contexts like in CVE
> reporting.
>
> For example Debian doesn't report containerd versions with leading "v".
>
> That's along the lines of what I thought. (I mean, in the end I doesn't
>
> matter how other distros and build systems have their versions, that
>
> is their choice and why we have the CVE version variable).
>
>
>
> If someone sends me a specific example of breakage (a tool and output),
>
> then I'd definitely be interested in seeing that. So that I can follow up
>
> on it in a bit more detail.
>
>
>
> The policy I have, and have always had (when possible, mistakes
>
> happen) is that PV matches the tag format of the repository. So in
>
> most of the projects that means "v". There's other tooling and processes
>
> that are looking to do that matching and have been around for a while.
>
>
>
> As long as the version doesn't obviously break semver, I've always
>
> just left it alone (and all the sever bits I've suffered say that the
>
> decorations don't make it incompatible..
>
>
>
> Fundamentally I don't worry about merging cosmetic changes, and
>
> when potentially new tools come along and ask the input formats
>
> and source to be changed, that's a problem for me .. since compatibility
>
> is nice, but so is consistency and backwards compatibility.
>
>
>
> Thanks for the follow up. Definitely helpful.
>
>
>
> Bruce
>
>
>
>
> Cheers,
>
> -Mikko
>
>
>
>
> --
>
> - Thou shalt not follow the NULL pointer, for chaos and madness await thee
> at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
>
>
>
> --
>
> - Thou shalt not follow the NULL pointer, for chaos and madness await thee
> at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#9388):
> https://lists.yoctoproject.org/g/meta-virtualization/message/9388
> Mute This Topic: https://lists.yoctoproject.org/mt/115111597/1050810
> Group Owner: meta-virtualization+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub [
> bruce.ashfield@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II

[-- Attachment #2: Type: text/html, Size: 18835 bytes --]

Re: [meta-virtualization] [PATCH] containerd: Remove leading "v" from PV

[Bruce Ashfield]

I didn't forget about this.

The version variables are ridciously all over the place.

I'm not doing it for this release, but for the LTS, I'll
unify them one way or the other, and I'm leaning towards
dropping the "v", since it isn't hugely important to me
and there's such a lack of consistency.

Bruce"

In message: [meta-virtualization] [PATCH] containerd: Remove leading "v" from PV
on 07/09/2025 Peter Kjellerstedt via lists.yoctoproject.org wrote:

> The leading "v" in the version otherwise makes its way into, e.g., the
> SBOM.
> 
> Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> ---
> 
> There are another 30 recipes in meta-virtualization that have a leading
> "v" in their versions, but this is the only one of them that we use.
> I can send patches for the others as well if you want.
> 
>  recipes-containers/containerd/containerd_git.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/recipes-containers/containerd/containerd_git.bb b/recipes-containers/containerd/containerd_git.bb
> index bae86146..c46d1673 100644
> --- a/recipes-containers/containerd/containerd_git.bb
> +++ b/recipes-containers/containerd/containerd_git.bb
> @@ -16,7 +16,7 @@ SRC_URI = "git://github.com/containerd/containerd;branch=release/2.1;protocol=ht
>  LICENSE = "Apache-2.0"
>  LIC_FILES_CHKSUM = "file://LICENSE;md5=1269f40c0d099c21a871163984590d89"
>  
> -CONTAINERD_VERSION = "v2.1.4"
> +CONTAINERD_VERSION = "2.1.4"
>  
>  # EXTRA_OEMAKE += "GODEBUG=1"
>  

> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#9377): https://lists.yoctoproject.org/g/meta-virtualization/message/9377
> Mute This Topic: https://lists.yoctoproject.org/mt/115111597/1050810
> Group Owner: meta-virtualization+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub [bruce.ashfield@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>