Why and when we need to migrate to newer #yocto version?

Why and when we need to migrate to newer #yocto version?

[requinham]

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

My question is about the #Yocto update and *maintenance strategy*. I have several projects for different boards and different versions of Yocto (1.7 2.0 2.2) which includes their BSP.

As an OS build system, especially GNU/Linux, I don't understand exactly when should we necessarily migrate to a new version?

In my understanding, the versions of the kernel, libraries and tools are independent from Yocto version. If you need to migrate to a new version of the Linux kernel, you have to modify/add the right recipe without worrying about the Yocto version.

Thus, the maintenance work -security, bugs, optimization- should relate to the recipes and not to Yocto itself.

Updating Yocto may have sens for me when we need to use new bitbake feature or new architecture but not to use new version of package. I think we should keep in mind to manage a certain consistency and compatibility between the different versions of the recipes in order for example to use the right version of the openssl library with the right version of Qt or even between the right version of the kernel and drivers, etc.
Thanks,
Mohamed

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

Re: [yocto] Why and when we need to migrate to newer #yocto version?

[Alexander Kanavin]

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

The versions of libraries and tools are not independent from Yocto
versions, in fact they are directly defined through oe-core metadata that
is in a specific Yocto version.

For examples, what version of openssl is in your yocto builds? Is it
supported/maintained upstream? What are you going to do if a critical
security vulnerability is discovered in that version?

This extends to all of the packages: it makes sense to use the most recent
Yocto version for two primary reasons:

- the stack is much less likely to contain security vulnerabilities
- it is much easier to satisfy project requirements w.r.t. version
compatibility, or needed features, if those features are only available in
recent versions of the package.

This mailing list gets horror stories all the time from people who are for
some reason using some ancient Yocto, then a customer requirement arrives
that can only be satisfied through updating to a newer Yocto, or
backporting a major component to the old Yocto; both impossible or nearly
impossible tasks. You do not want to end up in that situation.

Alex

On Thu, 4 Jun 2020 at 10:18, <requinham@gmail.com> wrote:

> My question is about the #Yocto update and *maintenance strategy*. I have
> several projects for different boards and different versions of Yocto (1.7
> 2.0 2.2) which includes their BSP.
>
> As an OS build system, especially GNU/Linux, I don't understand exactly
> when should we necessarily migrate to a new version?
>
> In my understanding, the versions of the kernel, libraries and tools are
> independent from Yocto version. If you need to migrate to a new version of
> the Linux kernel, you have to modify/add the right recipe without worrying
> about the Yocto version.
>
> Thus, the maintenance work -security, bugs, optimization- should relate to
> the recipes and not to Yocto itself.
>
> Updating Yocto may have sens for me when we need to use new bitbake
> feature or new architecture but not to use new version of package. I think
> we should keep in mind to manage a certain consistency and compatibility
> between the different versions of the recipes in order for example to use
> the right version of the openssl library with the right version of Qt or
> even between the right version of the kernel and drivers, etc.
> Thanks,
> Mohamed
> 
>

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

Re: [yocto] Why and when we need to migrate to newer #yocto version?

[requinham]

Thanks Alexander,

When you say "The versions of libraries and tools are not independent
from Yocto versions, in fact they are directly defined through oe-core
metadata that is in a specific Yocto version." This not concern Linux
kernel ? because Yocto wiki say "While tooling is provided to use any
Linux kernel you wish, the linux-yocto Linux kernel recipes are tested
with all the emulated targets, the core hardware BSPs, and some vendor
layers."
Then, you cited an important element for maintenance strategy : security issue .
Except the 3.1 LTS, each Yocto version is maintained for 2 releases so
for 1 year. Thus, for security fix, I think the normal way is to track
vulnerabilities and apply patch because migrating to newest Yocto
version every year represents a cost and an enormous effort whereas in
certain cases, all the evolution don't necessarily concern the system
which we uses.
Is my understanding correct?

Mohamed

On Thu, Jun 4, 2020 at 10:38 AM Alexander Kanavin
<alex.kanavin@gmail.com> wrote:
>
> The versions of libraries and tools are not independent from Yocto versions, in fact they are directly defined through oe-core metadata that is in a specific Yocto version.
>
> For examples, what version of openssl is in your yocto builds? Is it supported/maintained upstream? What are you going to do if a critical security vulnerability is discovered in that version?
>
> This extends to all of the packages: it makes sense to use the most recent Yocto version for two primary reasons:
>
> - the stack is much less likely to contain security vulnerabilities
> - it is much easier to satisfy project requirements w.r.t. version compatibility, or needed features, if those features are only available in recent versions of the package.
>
> This mailing list gets horror stories all the time from people who are for some reason using some ancient Yocto, then a customer requirement arrives that can only be satisfied through updating to a newer Yocto, or backporting a major component to the old Yocto; both impossible or nearly impossible tasks. You do not want to end up in that situation.
>
> Alex
>
> On Thu, 4 Jun 2020 at 10:18, <requinham@gmail.com> wrote:
>>
>> My question is about the #Yocto update and maintenance strategy. I have several projects for different boards and different versions of Yocto (1.7 2.0 2.2) which includes their BSP.
>>
>> As an OS build system, especially GNU/Linux, I don't understand exactly when should we necessarily migrate to a new version?
>>
>> In my understanding, the versions of the kernel, libraries and tools are independent from Yocto version. If you need to migrate to a new version of the Linux kernel, you have to modify/add the right recipe without worrying about the Yocto version.
>>
>> Thus, the maintenance work -security, bugs, optimization- should relate to the recipes and not to Yocto itself.
>>
>> Updating Yocto may have sens for me when we need to use new bitbake feature or new architecture but not to use new version of package. I think we should keep in mind to manage a certain consistency and compatibility between the different versions of the recipes in order for example to use the right version of the openssl library with the right version of Qt or even between the right version of the kernel and drivers, etc.
>> Thanks,
>> Mohamed
>>
>> 

Re: [yocto] Why and when we need to migrate to newer #yocto version?

[Alexander Kanavin]

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

On Thu, 4 Jun 2020 at 11:19, Mohamed HAMZAOUI <requinham@gmail.com> wrote:

> Thanks Alexander,
>
> When you say "The versions of libraries and tools are not independent
> from Yocto versions, in fact they are directly defined through oe-core
> metadata that is in a specific Yocto version." This not concern Linux
> kernel ? because Yocto wiki say "While tooling is provided to use any
> Linux kernel you wish, the linux-yocto Linux kernel recipes are tested
> with all the emulated targets, the core hardware BSPs, and some vendor
> layers."
>

Yes, the kernel is typically provided by the BSP vendor through the BSP
layer, and they define the kernel version in use. The security concerns
still apply though: if there is a vulnerability in their kernel, it's much
easier to address if the kernel is recent. And newer kernels gain new
features too, which might be useful or even required in the project.


> Then, you cited an important element for maintenance strategy : security
> issue .
> Except the 3.1 LTS, each Yocto version is maintained for 2 releases so
> for 1 year. Thus, for security fix, I think the normal way is to track
> vulnerabilities and apply patch because migrating to newest Yocto
> version every year represents a cost and an enormous effort whereas in
> certain cases, all the evolution don't necessarily concern the system
> which we uses.
> Is my understanding correct?
>

Tracking vulnerabilities and applying patches is a lot of work, and it
becomes harder, the further you are from upstream development. For two
reasons:

- security fixes need to be backported. To do that the code should not
change too much between the version that has the upstream fix, and version
that you need to patch. If you are far behind upstream, chances of that are
lower.

- if you can't apply the patch the way it is, and you need to change it,
you also need to truly understand what the code is doing and what the fix
changes in the code - and for most components that is not the case.

Also, after a Yocto version goes out of support (which happens fairly
quickly, previously one year, from now on 6 months for regular releases,
and 2 years for LTS ones), you need to do all of the vulnerability tracking
yourself; there typically is no shared community effort.

I would recommend the following strategy (and this is what we are using in
https://mbition.io/):

- there are two maintained branches, one 'rolling development' branch which
tracks master branches of all upstream layers and is periodically pushed
forward to bring in the latest upstream changes from all the layers, and
another 'stable product' branch which is based on the latest, supported LTS
release;

- when a new LTS release happens, 'rolling development' branch is split
into two: rolling development continues as it was, and a new 'stable
product' branch is created from the same code point. Previous LTS branch
can be retired then.

This way, there is never an enormous effort in migrating; instead the
migrating effort is spread over the 'rolling development' process, and is
continuous in nature.


Alex

>
> Mohamed
>
> On Thu, Jun 4, 2020 at 10:38 AM Alexander Kanavin
> <alex.kanavin@gmail.com> wrote:
> >
> > The versions of libraries and tools are not independent from Yocto
> versions, in fact they are directly defined through oe-core metadata that
> is in a specific Yocto version.
> >
> > For examples, what version of openssl is in your yocto builds? Is it
> supported/maintained upstream? What are you going to do if a critical
> security vulnerability is discovered in that version?
> >
> > This extends to all of the packages: it makes sense to use the most
> recent Yocto version for two primary reasons:
> >
> > - the stack is much less likely to contain security vulnerabilities
> > - it is much easier to satisfy project requirements w.r.t. version
> compatibility, or needed features, if those features are only available in
> recent versions of the package.
> >
> > This mailing list gets horror stories all the time from people who are
> for some reason using some ancient Yocto, then a customer requirement
> arrives that can only be satisfied through updating to a newer Yocto, or
> backporting a major component to the old Yocto; both impossible or nearly
> impossible tasks. You do not want to end up in that situation.
> >
> > Alex
> >
> > On Thu, 4 Jun 2020 at 10:18, <requinham@gmail.com> wrote:
> >>
> >> My question is about the #Yocto update and maintenance strategy. I have
> several projects for different boards and different versions of Yocto (1.7
> 2.0 2.2) which includes their BSP.
> >>
> >> As an OS build system, especially GNU/Linux, I don't understand exactly
> when should we necessarily migrate to a new version?
> >>
> >> In my understanding, the versions of the kernel, libraries and tools
> are independent from Yocto version. If you need to migrate to a new version
> of the Linux kernel, you have to modify/add the right recipe without
> worrying about the Yocto version.
> >>
> >> Thus, the maintenance work -security, bugs, optimization- should relate
> to the recipes and not to Yocto itself.
> >>
> >> Updating Yocto may have sens for me when we need to use new bitbake
> feature or new architecture but not to use new version of package. I think
> we should keep in mind to manage a certain consistency and compatibility
> between the different versions of the recipes in order for example to use
> the right version of the openssl library with the right version of Qt or
> even between the right version of the kernel and drivers, etc.
> >> Thanks,
> >> Mohamed
> >>
> >> 
>

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