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
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.
On Thu, Jun 4, 2020 at 10:38 AM Alexander Kanavin
> 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.
> On Thu, 4 Jun 2020 at 10:18, <requinham@...> 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.