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
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?
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, <firstname.lastname@example.org> 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.