10350 2016-09-29 23:05:40 +0000 devtool: deploy-target: deploy run time dependencies 2017-04-12 17:44:44 +0000 1 1 7 Build System, Metadata & Runtime OE-Core devtools / tool chain 2.2 x86 Multiple RESOLVED FIXED 12 April 2017: RESOLVED Medium+ normal 2.3 M4 10653 1 henry.bruce srifenbark bluelightning brian.avery meta.mr.watcher meta.watcher srifenbark tim.orling --- --- Done (doc changes complete) oldest_to_newest 66737 0 henry.bruce 2016-09-29 23:05:40 +0000 When running a 'devtool add' for new project 'foo' that introduces new runtime dependencies, the dependent packages are not deployed. So running 'devtool deploy-target foo' will succeed but running 'foo' on target will fail due to missing dependencies. An example would be creating npm packages with devtool for an image that does already include the node runtime. When you deploy the package, the node runtime is not present so the module cannot run. 66748 1 bluelightning 2016-09-30 09:30:56 +0000 To a degree this is intentional, because solving this is not straightforward. We know the runtime dependencies, and deploying those at the same time is pretty easy - but what we don't necessarily know is which of those dependencies are already satisfied on the target (worst case, it's an image we don't have metadata for with no runtime package management). If we can figure out a practical way of addressing that then I'm all for fixing it. 66765 2 henry.bruce 2016-09-30 16:31:10 +0000 We should make sure this limitation is documented while we work out a solution. Documentation should help developer work out which runtime dependencies need to be deployed ahead of time. 70780 3 brian.avery 2017-02-16 21:29:48 +0000 Henry could you document this as is? I'd also add that we could add a -f or 0a flag to deploy target that would copy all the runtime dependencies. so you could do a workflow like deploy-target -a cow modify/build cow deploy-target cow iterate.... basically let the user override to say, push all and then push just the target 70819 4 tim.orling 2017-02-19 06:08:35 +0000 +1 for 'devtool deploy-target -a cow' In upgrading libmodule-build-tiny-perl, I found that I could not test it on qemu without adding all the RDEPENDS to the image (there are 23 of them). I think it is acceptable to allow the developer to have a hammer which installs all the RDEPENDS (including overwriting those already on the target). What to do with undeploy becomes messier... some kind of uninstall manifest which tracks what was replaced? Another idea would be to perhaps provide a mechanism to bbappend the image package group and then performing 'devtool build-image core-image-foo-bar-baz' in the workspace. In this way we can help the developer understand what will be required to actually deploy the recipe in question. 71147 5 henry.bruce 2017-03-08 19:32:39 +0000 I agree with Brian's -a option to deploy all dependencies. However this will require further discussion with Paul and should should be a 2.4 feature. In the meantime, I assign to Scott so docs are updated to make sure developers know that devtool will not deploy dependencies. Once that's done, we can set target milestone to 2.4. 71217 6 srifenbark 2017-03-13 20:13:27 +0000 Accepting - I will put the appropriate warnings and behaviors in the existing doc for now. Scott 71223 7 srifenbark 2017-03-13 20:37:43 +0000 Look at this section in the sdk-manual - http://www.yoctoproject.org/docs/2.3/sdk-manual/sdk-manual.html#sdk-dependency-detection-and-mapping. It is titled "Dependency Detection and Mapping" and is a subsection of the "http://www.yoctoproject.org/docs/2.3/sdk-manual/sdk-manual.html#sdk-a-closer-look-at-devtool-add" section. It talks about dependencies. Does the information in this section apply to the problem here? 71226 8 henry.bruce 2017-03-13 20:43:45 +0000 The section you found refers to the devtool "add" sub-command and how to manually edit a recipe if it fails to automatically determine run-time dependencies. This bug refers to the "deploy-target" sub-command, where we assume runtime dependencies have been correctly defined in recipe but the tool does not deploy them to the target. Make sense? 71255 9 srifenbark 2017-03-14 16:21:57 +0000 Hey Henry, I get it that the issue is more with deploy. However, that section about dependencies probably needs a pointer to the explanation as devtool add apparently does not work as expected right in setting up and knowing about all dependencies. Isn't it just the action of deploying that unveils this? So a solution I think would be to describe the issue in a devtool deploy area but have some sort of pointer or reference from devtool add section whose topic matter is indeed about dependencies. In the ref-manual, there is a quick reference on devtool (http://www.yoctoproject.org/docs/2.3/ref-manual/ref-manual.html#ref-devtool-reference). Further down in that section is a subsection named "Deploying Your Software on the Target Machine" at http://www.yoctoproject.org/docs/2.3/ref-manual/ref-manual.html#devtool-deploying-your-software-on-the-target-machine. Right now, this section has nothing of sort about software not running correctly due to missing dependencies. It seems this would be the place to detail the issue in this bug. Correct? Thanks, Scott 71407 10 srifenbark 2017-03-17 17:56:23 +0000 Changing back to Scott and setting to IN PROGRESS DESIGN. 71428 11 srifenbark 2017-03-18 19:35:25 +0000 Henry, See the additional information at the bottom of the http://www.yoctoproject.org/docs/2.3/ref-manual/ref-manual.html#devtool-deploying-your-software-on-the-target-machine section to describe this situation. Make sure I am covering the bases here. Also, see the note added to the http://www.yoctoproject.org/docs/2.3/ref-manual/ref-manual.html#devtool-adding-a-new-recipe-to-the-workspace section to cross-reference the situation. Let me know of any tweaks, changes, etc. Scott 71468 12 srifenbark 2017-03-20 17:50:15 +0000 Setting to 2.3 M4. 71765 13 henry.bruce 2017-03-27 19:09:28 +0000 If feel the wording could be clearer but it gets the message across. I recommend you move the new paragraph closer to the the existing description of deploy-target operation "This command deploys all files installed during the do_install task" as this will help clarify that no dependent packages will be deployed. 71778 14 srifenbark 2017-03-27 21:25:05 +0000 Henry, I reworded that first bullet of the new information after the note. I don't want to move that block of information though. The reason I don't is because the section introduces the command basics and then the new information is additional information about some finer points of using the command. I am going to leave that structure in place. I am open to any rewordings you think might make the text clearer. Thanks, Scott 71781 15 henry.bruce 2017-03-27 21:37:28 +0000 Thanks Scott. Looks good. That should do it for warning user of current behavior. Question: Do we leave this bug open for implementation in 2.4 or close it and open a new one? 71784 16 srifenbark 2017-03-27 22:06:58 +0000 Hi Henry, I would say we close this one and open a new one. If they fix the behavior for 2.4 then the documentation component of the bug would be to update the manual back to "normal" (or however it will behave for 2.4). Scott 72395 17 srifenbark 2017-04-12 17:44:44 +0000 Closing... the doc part is done. Scott