Moving all writable data under /var
Description
Environment
relates to
Activity
Jose Bollo May 12, 2017 at 3:25 PM
We are waiting for the pending review https://gerrit.automotivelinux.org/gerrit/#/c/9071
Jan-Simon Moeller April 10, 2017 at 2:43 PM
And dlcsrv_REL is being moved into a debug package anyway. We could correct the path then, too.
https://gerrit.automotivelinux.org/gerrit/#/c/9069/
@ see discussion above.
Jose Bollo April 10, 2017 at 2:33 PM
on m3 I only have /usr/local/bin/dlcsrv_REL
these files are used by AGL/wayland
I agree with that "in principle as a 'distro' we should not ship anything in /usr/local at all."
Jan-Simon Moeller April 10, 2017 at 2:25 PM
In principle as a 'distro' we should not ship anything in /usr/local at all.
Jan-Simon Moeller April 10, 2017 at 2:24 PM
So thats likely all from the gen2 BSP (and we iirc have quite a few hacks in place to bend paths around to /usr/local/lib for this). If that is the only user, we should fix the BSP. It might likewise be the case on m3 and h3 . We need to quick-check the other BSP's, too.
Details
Details
Assignee
Jose BolloReporter
Anton GerasimovFix versions
Labels
Contract ID
Components
Priority
Major
Right now application framework is in conflict with OTA updates.
Basically, OSTree requires data to be separated to updatable, which is generated on build and should be read-only and non-updatable which can be written, but should be generated fully in runtime. That means that it is not directly possible to build a filesystem image with some initial database and then commit to it in the runtime.
It is not just a technical limitation of OSTree, it is actually quite logical if we want our filesystem to be updatable: imagine that we deployed an image with some initial database and then installed some applications in runtime. We then create a new filesystem image in Yocto with refactored initial database system and trying to update our device. The problem of merging two database files is then emerging and it can't be solved automatically in general case.
The simplest thing that can be done if we still want to have some data that is initialized on build stage and can be updated in runtime is
Install it to /usr/var/foo
Write a oneshot service that will deploy /usr/var/foo to /var/foo if /var/foo doesn't exist.
Currently affected recipes are as far as I'm concerned af_main (meta-agl-extra/meta-app-framework/recipes-core/af-main/af-main_1.0.bb) and security-manager (meta-intel-iot-security/meta-security-framework/recipes-security/security-manager/).