recipes-sota: Bump aktualizr-lite#430
Conversation
| FILES_${PN}-lite += "${nonarch_libdir}/tmpfiles.d/aktualizr-lite.conf" | ||
|
|
||
| FILES_${PN}-lite-lib = "${libdir}/libaktualizr_lite.so" | ||
| FILES_${PN}-dev += "${includedir}/${PN}-lite ${includedir}/json" |
There was a problem hiding this comment.
What exactly are we installing under ${includedir}/json? Just curious because this is a generic path that has a potential to conflict with other packages.
There was a problem hiding this comment.
i was worried this might be a problem. aktualizr pulls in a third-party dependency as a git submodule:
There was a problem hiding this comment.
Hm, there is a recipe for that in OE already, do we want to use the version available as a submodule or should we just handle it as an external dependency and build using the jsoncpp recipe instead?
There was a problem hiding this comment.
the need for json headers doesn't become a problem until you build a custom client. i thought about making my custom client recipe try and pull in jsoncpp as a dependency. However, then I fear you'd get into version mismatch issues.
i also thought about making it "aktualizr-lite/json/json.h" but that causes friction when doing local aklite/aktualizr development.
Not sure this would work, but what if we had this recipe depend on jsoncpp and do some compile_prepend type hack that replaces aktualizr/third_party/jsoncpp with OE's?
There was a problem hiding this comment.
Seems the upstream project is not doing that many releases lately, so not sure if we should be concerned with version mismatch, but will let that one for you as you are consuming it.
From the OE perspective I would just add jsoncpp as a build dependency in aktualizr-lite if used by the project, otherwise I would not install anything here and let the client have jsoncpp as a build dependency, as this is just another generic third-party dependency.
There was a problem hiding this comment.
To some extend this case is similar to aklite dependency on dockerd, docker and docker-compose. Test and dev flow uses the utilities installed in the test container and a dev local/container host and a version of these utilities doesn't always match the version defined in LmP. Thus, the final testing happens on actual device/VM, so it could be the same for jsoncpp dependency.
There was a problem hiding this comment.
i've force pushed a change that drops the HEAD commit in aklite: foundriesio/aktualizr-lite@87fde29
I think we should just revert that change. I've built my custom client with a DEPENDS on jsoncpp and things work fine
There was a problem hiding this comment.
Cool, then better to just drop the jsoncpp piece.
There was a problem hiding this comment.
oops - i forgot to git-push yesterday. fixed now.
This brings in a new version of aktualizr-lite that can be built as an api and shared library for custom clients to extend. Other changes include: * 68325ced - Fix hwinfo reporting on x86 Signed-off-by: Andy Doan <[email protected]>
mike-sul
left a comment
mike-sul
left a comment
There was a problem hiding this comment.
I guess this commit should be removed foundriesio/aktualizr-lite@87fde29
Yep, i'm going to do a git-revert PR for that in a bit. |
This reverts commit 87fde29. Turns out the better way of handling this in OE is to depend on the jsoncpp package: https://github.com/foundriesio/meta-lmp/pull/430#discussion_r714812071` Signed-off-by: Andy Doan <[email protected]>
3 participants
This brings in a new version of aktualizr-lite that can be built as
an api and shared library for custom clients to extend.
Other changes include:
Signed-off-by: Andy Doan [email protected]