devtool deploy-target: optionally specify package
PATCH 1/1 devtool deploy-target: optionally specify package
Instead of installing an entire recipe's build output (i.e. ${D}), allow the user to optionally specify a package from said recipe to be installed exclusively (i.e. ${PKGDEST}/<package>).
--- scripts/lib/devtool/deploy.py | 26 ++++++++++++++++++-------- 1 file changed, 18 insertions(+), 8 deletions(-)
scripts/lib/devtool/deploy.py +18 -8
@@ -169,11 +169,20 @@ def deploy(args, config, basepath, workspace): except Exception as e: raise DevtoolError('Exception parsing recipe %s: %s' % (args.recipename, e)) - recipe_outdir = rd.getVar('D') + if args.package: + recipe_outdir = os.path.join(rd.getVar('PKGDEST'), args.package) + else: + recipe_outdir = rd.getVar('D') if not os.path.exists(recipe_outdir) or not os.listdir(recipe_outdir): - raise DevtoolError('No files to deploy - have you built the %s ' - 'recipe? If so, the install step has not installed ' - 'any files.' % args.recipename) + if args.package: + raise DevtoolError('No files to deploy - have you built the %s ' + 'package of the %s recipe? If so, the install ' + 'step has not installed any files.' + % (args.package, args.recipename)) + else: + raise DevtoolError('No files to deploy - have you built the %s ' + 'recipe? If so, the install step has not installed ' + 'any files.' % args.recipename) if args.strip and not args.dry_run: # Fakeroot copy to new destination
@@ -314,8 +323,8 @@ def register_commands(subparsers, context): """Register devtool subcommands from the deploy plugin""" parser_deploy = subparsers.add_parser('deploy-target', - help='Deploy recipe output files to live target machine', - description='Deploys a recipe\'s build output (i.e. the output of the do_install task) to a live target machine over ssh. By default, any existing files will be preserved instead of being overwritten and will be restored if you run devtool undeploy-target. Note: this only deploys the recipe itself and not any runtime dependencies, so it is assumed that those have been installed on the target beforehand.', + help='Deploy build output to a live target machine', + description='Deploys either the full recipe\'s build output (i.e. the output of the do_install task) or a package of a recipe to a live target machine over ssh. By default, any existing files will be preserved instead of being overwritten and will be restored if you run devtool undeploy-target. Note: this only deploys the specified item itself and not any runtime dependencies, so it is assumed that those have been installed on the target beforehand.', group='testbuild') parser_deploy.add_argument('recipename', help='Recipe to deploy') parser_deploy.add_argument('target', help='Live target machine running an ssh server: user@hostname[:destdir]')
@@ -325,6 +334,7 @@ def register_commands(subparsers, context): parser_deploy.add_argument('-p', '--no-preserve', help='Do not preserve existing files', action='store_true') parser_deploy.add_argument('--no-check-space', help='Do not check for available space before deploying', action='store_true') parser_deploy.add_argument('-P', '--port', help='Specify port to use for connection to the target') + parser_deploy.add_argument('--package', help='Specify a recipe\'s package to deploy', dest='package') strip_opts = parser_deploy.add_mutually_exclusive_group(required=False) strip_opts.add_argument('-S', '--strip',
@@ -337,8 +347,8 @@ def register_commands(subparsers, context): parser_deploy.set_defaults(func=deploy) parser_undeploy = subparsers.add_parser('undeploy-target', - help='Undeploy recipe output files in live target machine', - description='Un-deploys recipe output files previously deployed to a live target machine by devtool deploy-target.', + help='Undeploy output files from a live target machine', + description='Un-deploys output files previously deployed to a live target machine by devtool deploy-target.', group='testbuild') parser_undeploy.add_argument('recipename', help='Recipe to undeploy (if not using -a/--all)', nargs='?') parser_undeploy.add_argument('target', help='Live target machine running an ssh server: user@hostname')
Signature · 1 line
2.17.0.582.gccdcbd54c
Quoted 3 lines · Trevor Woerner
Instead of installing an entire recipe's build output (i.e. ${D}), allow the user to optionally specify a package from said recipe to be installed exclusively (i.e. ${PKGDEST}/<package>).
I'm not a big devtool user myself, but I'm curious about the situations where you might need this?
Are the going to be problems if users want to deploy more than one package (or switch between a full deploy and a package) and don't deploy and undeploy in the right order?
Quoted 72 lines
Signed-off-by Trevor Woerner <[email protected]>--- scripts/lib/devtool/deploy.py | 26 ++++++++++++++++++-------- 1 file changed, 18 insertions(+), 8 deletions(-)scripts/lib/devtool/deploy.py +18
-9@@ -169,11 +169,20 @@ def deploy(args, config, basepath, workspace): except Exception as e: raise DevtoolError('Exception parsing recipe %s: %s' % (args.recipename, e)) - recipe_outdir = rd.getVar('D') + if args.package: + recipe_outdir = os.path.join(rd.getVar('PKGDEST'), args.package) + else: + recipe_outdir = rd.getVar('D') if not os.path.exists(recipe_outdir) or not os.listdir(recipe_outdir): - raise DevtoolError('No files to deploy - have you built the %s ' - 'recipe? If so, the install step has not installed ' - 'any files.' % args.recipename) + if args.package: + raise DevtoolError('No files to deploy - have you built the %s ' + 'package of the %s recipe? If so, the install ' + 'step has not installed any files.' + % (args.package, args.recipename)) + else: + raise DevtoolError('No files to deploy - have you built the %s ' + 'recipe? If so, the install step has not installed ' + 'any files.' % args.recipename) if args.strip and not args.dry_run: # Fakeroot copy to new destination@@ -314,8 +323,8 @@ def register_commands(subparsers, context): """Register devtool subcommands from the deploy plugin""" parser_deploy = subparsers.add_parser('deploy-target', - help='Deploy recipe output files to live target machine', - description='Deploys a recipe\'s build output (i.e. the output of the do_install task) to a live target machine over ssh. By default, any existing files will be preserved instead of being overwritten and will be restored if you run devtool undeploy-target. Note: this only deploys the recipe itself and not any runtime dependencies, so it is assumed that those have been installed on the target beforehand.', + help='Deploy build output to a live target machine', + description='Deploys either the full recipe\'s build output (i.e. the output of the do_install task) or a package of a recipe to a live target machine over ssh. By default, any existing files will be preserved instead of being overwritten and will be restored if you run devtool undeploy-target. Note: this only deploys the specified item itself and not any runtime dependencies, so it is assumed that those have been installed on the target beforehand.', group='testbuild') parser_deploy.add_argument('recipename', help='Recipe to deploy') parser_deploy.add_argument('target', help='Live target machine running an ssh server: user@hostname[:destdir]')@@ -325,6 +334,7 @@ def register_commands(subparsers, context): parser_deploy.add_argument('-p', '--no-preserve', help='Do not preserve existing files', action='store_true') parser_deploy.add_argument('--no-check-space', help='Do not check for available space before deploying', action='store_true') parser_deploy.add_argument('-P', '--port', help='Specify port to use for connection to the target') + parser_deploy.add_argument('--package', help='Specify a recipe\'s package to deploy', dest='package') strip_opts = parser_deploy.add_mutually_exclusive_group(required=False) strip_opts.add_argument('-S', '--strip',@@ -337,8 +347,8 @@ def register_commands(subparsers, context): parser_deploy.set_defaults(func=deploy) parser_undeploy = subparsers.add_parser('undeploy-target', - help='Undeploy recipe output files in live target machine', - description='Un-deploys recipe output files previously deployed to a live target machine by devtool deploy-target.', + help='Undeploy output files from a live target machine', + description='Un-deploys output files previously deployed to a live target machine by devtool deploy-target.', group='testbuild') parser_undeploy.add_argument('recipename', help='Recipe to undeploy (if not using -a/--all)', nargs='?') parser_undeploy.add_argument('target', help='Live target machine running an ssh server: user@hostname') --2.17.0.582.gccdcbd54c
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Hi Andre, thanks for taking an interest!
Quoted 10 lines · Andre McCurdy
Quoted 1 line · Trevor Woerner
Instead of installing an entire recipe's build output (i.e. ${D}), allow
the
Quoted 2 lines
user to optionally specify a package from said recipe to be installed exclusively (i.e. ${PKGDEST}/<package>).
I'm not a big devtool user myself, but I'm curious about the situations where you might need this?
Earlier today I was working on recipes for some software which recently added the feature to dlopen() one of a couple shared objects based on various conditions. But instead of dlopen()'ing the SONAME, they were dlopen()'ing the raw .so file. OE's default packaging, of course, added the *.so.0 and *.so.0.0.0 files to the ${PN} package, and the raw *.so files to the ${PN}-dev package. So when the app tried to run, it failed.
Investigating, I realised there were two things I could do: 1) add the raw *.so files to the ${PN} package (with INSANE_SKIP += "dev-so") or 2) fix the app. I decided to try #2, with the help of devtool.
I made one small change to the app, "devtool deploy-target"'ed it, and, AMAZINGLY, everything worked!! Wow, what luck! ... or not.
Investigating, I discovered that "devtool deploy-target"'s only mode of operation is to upload the entire recipe's ${D} directory (i.e. ${WORKDIR}/image) to the target! I hope you'll be as surprised by that as am I. Considering ${D} includes *.a files, man pages, raw *.so files, pkgconfigs, (... thankfully it doesn't also include the -dbg packages) that is a lot of stuff to be uploading to the target, a lot of wrong stuff, and in my case that hindered my work. Most target filesystems are only 10% larger than required to hold their contents, so uploading static libraries, man pages, pkgconfigs, etc is not great.
Specifically, these unwanted raw *.so files were hindering my work. My only two options were: 1) to use "devtool deploy-target" as-is and then have to manually delete all the .so files or 2) come up with a better solution. I went with #2 (again).
Many recipes generate just a couple packages: ${PN}, -dbg, -doc, -dev, -staticdev, -locale. But some generate a whole bunch. In my case my recipe is generating a lot of packages, but I only wanted to investigate one. This patch allows a developer to focus on just one package, instead of the entire recipe.
Quoted 4 lines
Are the going to be problems if users want to deploy more than one package (or switch between a full deploy and a package) and don't deploy and undeploy in the right order?
In my patch I added a --package option to "devtool deploy-target" but not to "devtool undeploy-target". devtool keeps track of what files were uploaded by creating a per-package list on the target itself (in /.devtool). When you undeploy a recipe, it simply looks for this recipe file on the target, reads the files listed there, and undeploys each of the files in that list.
Therefore, mixing and matching deploys and undeploys amongst recipes don't interfere with each other.
I checked at the time, but I'm not 100% sure now, but I believe if one deploys two packages from one recipe, the on-target file gets appended. But now I'm not 100% sure, so I'll verify this tomorrow (thanks for the reminder). As such, under my scheme, you can deploy recipes and packages at will, but then only undeploy the whole kit and caboodle in one go; given a recipe name to undeploy, whatever it finds in the on-target record will get undeployed.
I think any developer will find this reasonable behaviour (but maybe not?).
In any case, my patch doesn't affect any existing workflows. If a developer never notices the new --package option and simply continues to use "devtool deploy-target" with just a recipe name, the behaviour will be exactly the same. Only when the --package option is used will the new behaviour occur.
I'll verify deploying multiple packages from the same recipe to confirm they append the list file. I'll also verify deploying the same package multiple times (although my guess is there'll be no difference between this and the existing behaviour should one deploy the same recipe multiple times).
Quoted 14 lines · Trevor Woerner
Hi Andre, thanks for taking an interest!
Quoted 10 lines · Andre McCurdy
Quoted 4 lines · Trevor Woerner
Instead of installing an entire recipe's build output (i.e. ${D}), allow the
user to optionally specify a package from said recipe to be installed exclusively (i.e. ${PKGDEST}/<package>).I'm not a big devtool user myself, but I'm curious about the situations where you might need this?
Quoted 6 lines
Earlier today I was working on recipes for some software which recently added the feature to
dlopen()one of a couple shared objects based on various conditions. But instead of dlopen()'ing the SONAME, they were dlopen()'ing the raw .so file. OE's default packaging, of course, added the *.so.0 and *.so.0.0.0 files to the ${PN} package, and the raw *.so files to the ${PN}-dev package. So when the app tried to run, it failed.
Sounds familiar. I used to maintain this patch for the mesa recipe to workaround a similar issue in Qt:
http://lists.openembedded.org/pipermail/openembedded-devel/2015-May/101455.html
I don't know if later versions of Qt still show the problem (and of course, the workaround in the mesa recipe was never merged...).
Quoted 22 lines
Investigating, I realised there were two things I could do: 1) add the raw *.so files to the ${PN} package (with
INSANE_SKIP+= "dev-so") or 2) fix the app. I decided to try #2, with the help of devtool.I made one small change to the app, "devtool deploy-target"'ed it, and, AMAZINGLY, everything worked!! Wow, what luck! ... or not.
Investigating, I discovered that "devtool deploy-target"'s only mode of operation is to upload the entire recipe's ${D} directory (i.e. ${WORKDIR}/image) to the target! I hope you'll be as surprised by that as am I. Considering ${D} includes *.a files, man pages, raw *.so files, pkgconfigs, (... thankfully it doesn't also include the -dbg packages) that is a lot of stuff to be uploading to the target, a lot of wrong stuff, and in my case that hindered my work. Most target filesystems are only 10% larger than required to hold their contents, so uploading static libraries, man pages, pkgconfigs, etc is not great.
Specifically, these unwanted raw *.so files were hindering my work. My only two options were: 1) to use "devtool deploy-target" as-is and then have to manually delete all the .so files or 2) come up with a better solution. I went with #2 (again).
Quoted 5 lines
Many recipes generate just a couple packages: ${PN}, -dbg, -doc, -dev, -staticdev, -locale. But some generate a whole bunch. In my case my recipe is generating a lot of packages, but I only wanted to investigate one. This patch allows a developer to focus on just one package, instead of the entire recipe.
All seems reasonable to me. Thanks for taking the time to explain all the details!
I wonder whether the default behaviour should just be to not deploy files from the -dev package?
Quoted 22 lines
Quoted 3 lines
Are the going to be problems if users want to deploy more than one package (or switch between a full deploy and a package) and don't deploy and undeploy in the right order?
In my patch I added a --package option to "devtool deploy-target" but not to "devtool undeploy-target". devtool keeps track of what files were uploaded by creating a per-package list on the target itself (in /.devtool). When you undeploy a recipe, it simply looks for this recipe file on the target, reads the files listed there, and undeploys each of the files in that list.
Therefore, mixing and matching deploys and undeploys amongst recipes don't interfere with each other.
I checked at the time, but I'm not 100% sure now, but I believe if one deploys two packages from one recipe, the on-target file gets appended. But now I'm not 100% sure, so I'll verify this tomorrow (thanks for the reminder). As such, under my scheme, you can deploy recipes and packages at will, but then only undeploy the whole kit and caboodle in one go; given a recipe name to undeploy, whatever it finds in the on-target record will get undeployed.
Quoted 1 line
I think any developer will find this reasonable behaviour (but maybe not?).
If that's how it works then it seems reasonable to me.
Quoted 9 lines
In any case, my patch doesn't affect any existing workflows. If a developer never notices the new --package option and simply continues to use "devtool deploy-target" with just a recipe name, the behaviour will be exactly the same. Only when the --package option is used will the new behaviour occur.
I'll verify deploying multiple packages from the same recipe to confirm they append the list file. I'll also verify deploying the same package multiple times (although my guess is there'll be no difference between this and the existing behaviour should one deploy the same recipe multiple times).
Quoted 7 lines · Andre McCurdy
On Thu, May 31, 2018 at 7:23 PM, Trevor Woerner <[email protected]> wrote:
I wonder whether the default behaviour should just be to not deploy files from the -dev package?
That would certainly be an improvement. But it still wouldn't make sense to copy over the -staticdev or -doc packages either. Maybe a better default behaviour would be to not copy over the -dev, -staticdev, -doc, -dbg, and -locale packages? Or better yet: just copy over the core packages, not any of the core-<something> packages? I'm guessing bitbake has a list somewhere of these -somethings?
I wouldn't be surprised if the current behaviour exists simply because ${D} is already there and ready to go. My tweak extends the behaviour to send another already-there directory: ${PKGDEST} + <package>.
If we were to go this route (i.e. being more selective about which packages are sent) do you think this should be the new default behaviour, or should the existing default behaviour be preserved and a flag used for this tweak?
Quoted 27 lines
Quoted 6 lines
Quoted 3 lines
Are the going to be problems if users want to deploy more than one package (or switch between a full deploy and a package) and don't deploy and undeploy in the right order?
In my patch I added a --package option to "devtool deploy-target" but
not to
Quoted 1 line
"devtool undeploy-target". devtool keeps track of what files were
uploaded
Quoted 1 line
by creating a per-package list on the target itself (in /.devtool). When
you
Quoted 1 line
undeploy a recipe, it simply looks for this recipe file on the target,
reads
Quoted 3 lines
the files listed there, and undeploys each of the files in that list.
Therefore, mixing and matching deploys and undeploys amongst recipes
don't
Quoted 4 lines
interfere with each other.
I checked at the time, but I'm not 100% sure now, but I believe if one deploys two packages from one recipe, the on-target file gets appended.
But
Quoted 2 lines
now I'm not 100% sure, so I'll verify this tomorrow (thanks for the reminder). As such, under my scheme, you can deploy recipes and packages
at
Quoted 1 line
will, but then only undeploy the whole kit and caboodle in one go; given
a
Quoted 10 lines
Quoted 1 line
recipe name to undeploy, whatever it finds in the on-target record will
get
Quoted 3 lines
undeployed.
I think any developer will find this reasonable behaviour (but maybe
not?).
If that's how it works then it seems reasonable to me.
Unfortunately this morning's investigation shows this is not the case. When a recipe is deployed to the target, the on-target script looks for evidence of this recipe having already been deployed. If that is the case, it undeploys the previous deploy before deploying this deploy. That is very good behaviour since it catches the cases where the file list might change between deployments. But with my tweak as-is, if the user deploys two packages from the same recipe, the first one will be undeployed and only the second one will remain deployed; this is not reasonable.
Therefore a v2 will be necessary. The question is, which route do I take?
Quoted 4 lines · Trevor Woerner
Quoted 3 lines · Andre McCurdy
On Thu, May 31, 2018 at 7:23 PM, Trevor Woerner <[email protected]> wrote:
Quoted 8 lines
Quoted 3 lines
I wonder whether the default behaviour should just be to not deploy files from the -dev package?
That would certainly be an improvement. But it still wouldn't make sense to copy over the -staticdev or -doc packages either. Maybe a better default behaviour would be to not copy over the -dev, -staticdev, -doc, -dbg, and -locale packages?
Right. The list of packages to blacklist by default would need some thought and it's probably more than just the -dev package.
Quoted 3 lines
Or better yet: just copy over the core packages, not any
of the core-<something> packages? I'm guessing bitbake has a list somewhere of these -somethings?
The core packages can be named almost anything, so blacklisting the packages which shouldn't be deployed is going to be easier than whitelisting core packages which should be deployed.
Quoted 7 lines
I wouldn't be surprised if the current behaviour exists simply because ${D} is already there and ready to go. My tweak extends the behaviour to send another already-there directory: ${PKGDEST} + <package>.
If we were to go this route (i.e. being more selective about which packages are sent) do you think this should be the new default behaviour, or should the existing default behaviour be preserved and a flag used for this tweak?
I was thinking maybe to exclude -dev packages etc by default and provide a new command line option to over-ride that and deploy everything (ie a new command line option gets you back to the current behaviour).
I don't know whether there's a common use case in the devtool workflow which relies on -dev packages etc being deployed and would be broken by that change in behaviour though.
Quoted 47 lines
Quoted 31 lines
Quoted 31 lines
Quoted 3 lines
Are the going to be problems if users want to deploy more than one package (or switch between a full deploy and a package) and don't deploy and undeploy in the right order?
In my patch I added a --package option to "devtool deploy-target" but not to
"devtool undeploy-target". devtool keeps track of what files were uploaded
by creating a per-package list on the target itself (in /.devtool). When you
undeploy a recipe, it simply looks for this recipe file on the target, reads
the files listed there, and undeploys each of the files in that list.Therefore, mixing and matching deploys and undeploys amongst recipes don't
interfere with each other.I checked at the time, but I'm not 100% sure now, but I believe if one deploys two packages from one recipe, the on-target file gets appended. But
now I'm not 100% sure, so I'll verify this tomorrow (thanks for the reminder). As such, under my scheme, you can deploy recipes and packages at
will, but then only undeploy the whole kit and caboodle in one go; given a
recipe name to undeploy, whatever it finds in the on-target record will get
undeployed.Quoted 5 lines
Quoted 2 lines
I think any developer will find this reasonable behaviour (but maybe not?).
If that's how it works then it seems reasonable to me.
Unfortunately this morning's investigation shows this is not the case. When a recipe is deployed to the target, the on-target script looks for evidence of this recipe having already been deployed. If that is the case, it undeploys the previous deploy before deploying this deploy. That is very good behaviour since it catches the cases where the file list might change between deployments. But with my tweak as-is, if the user deploys two packages from the same recipe, the first one will be undeployed and only the second one will remain deployed; this is not reasonable.
Therefore a v2 will be necessary. The question is, which route do I take?
Hi Trevor,
Quoted 14 lines · NZST Trevor Woerner
Earlier today I was working on recipes for some software which recently added the feature to
dlopen()one of a couple shared objects based on various conditions. But instead of dlopen()'ing the SONAME, they were dlopen()'ing the raw .so file. OE's default packaging, of course, added the *.so.0 and *.so.0.0.0 files to the ${PN} package, and the raw *.so files to the ${PN}-dev package. So when the app tried to run, it failed.Investigating, I realised there were two things I could do: 1) add the raw *.so files to the ${PN} package (with
INSANE_SKIP+= "dev-so") or 2) fix the app. I decided to try #2, with the help of devtool.I made one small change to the app, "devtool deploy-target"'ed it, and, AMAZINGLY, everything worked!! Wow, what luck! ... or not.
Quoted 9 lines
Investigating, I discovered that "devtool deploy-target"'s only mode of operation is to upload the entire recipe's ${D} directory (i.e. ${WORKDIR}/image) to the target! I hope you'll be as surprised by that as am I. Considering ${D} includes *.a files, man pages, raw *.so files, pkgconfigs, (... thankfully it doesn't also include the -dbg packages) that is a lot of stuff to be uploading to the target, a lot of wrong stuff, and in my case that hindered my work. Most target filesystems are only 10% larger than required to hold their contents, so uploading static libraries, man pages, pkgconfigs, etc is not great.
This is intentional. The reason we do it this way is it frees the user from having to resolve any packaging issues that might otherwise prevent them from actually getting early development code onto the device to test - package QA, but also what if important files simply aren't in the right package? The user will then have to go and figure out how to fix that before they can get any further. devtool is supposed to shorten people's development cycles, especially if it's early in development and they tend to be a bit less patient to see something working on target.
Now, I appreciate that the flipside of the same coin is that there are issues we might pick up as part of package QA that would be helpful to highlight to the user (e.g. binary architecture was wrong), so it may be that we should revisit this, but I wouldn't want to wholesale switch over to packaging output by default - we'd need to be a bit more careful about it.
I will note that a small issue with your patch is that if you do use --package you can no longer just use devtool build to build what you need to deploy, since that only builds up to do_populate_sysroot / do_packagedata. This in turn means that you can't use this option within the eSDK as you can't conveniently run bitbake there (again, intentional).
I'm not violently opposed to this patch, but everyone does need to understand what the caveats are so we may need some extra notes in the help text at a minimum.
Quoted 4 lines
I checked at the time, but I'm not 100% sure now, but I believe if one deploys two packages from one recipe, the on-target file gets appended. But now I'm not 100% sure, so I'll verify this tomorrow (thanks for the reminder).
The way I recall writing it, it will remove whatever it deployed last time, so I would be surprised if it were incremental.
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Hi Paul,
I was hoping you'd notice and provide feedback :-D
Quoted 7 lines · Paul Eggleton
Quoted 4 lines
I checked at the time, but I'm not 100% sure now, but I believe if one deploys two packages from one recipe, the on-target file gets appended. But now I'm not 100% sure, so I'll verify this tomorrow (thanks for the reminder).
The way I recall writing it, it will remove whatever it deployed last time, so I would be surprised if it were incremental.
Yes, further investigation demonstrated this to be the case. This is a good feature, since it handles the case where files or filenames might change between deployments.
I've since updated the patch (locally) so that the on-target filenames of the deployments, e.g. <recipe>.list and <recipe>.preserve, now include the optional packagename (if this option is used): e.g. <recipe>.<package>.list and <recipe>.<package>.preserve. In this way a user can deploy and undeploy multiple packages from the same recipe independently of each other without any of them clobbering the other.
The only caveat, now, would be if the user then deployed the entire recipe. In this case the on-target files would still be the things the user was working on; the "problem" would be an inconsistency in the on-target devtool accounting files. In other words, it would be inadvisable to mix and match between using and not using the --package option within the same recipe.
Best regards,
Trevor
Quoted 6 lines · NZST Paul Eggleton
I will note that a small issue with your patch is that if you do use -- package
you can no longer just use devtool build to build what you need to deploy, since that only builds up todo_populate_sysroot/do_packagedata. This in turn means that you can't use this option within the eSDK as you can't conveniently run bitbake there (again, intentional).
Clearly I'm trying to do too many things this morning - this is completely wrong, do_packagedata depends on do_package so there shouldn't be a problem here. The rest of my reply stands though.
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Quoted 4 lines · Trevor Woerner
Instead of installing an entire recipe's build output (i.e. ${D}), allow the user to optionally specify a package from said recipe to be installed exclusively (i.e. ${PKGDEST}/<package>).
Thinking of developer's workflow, it might be needed to be able to install debug/dev packages to debug the package on device.
although I think we should be able to segment it and may be have an option to install the dev part separately
Quoted 65 lines
Signed-off-by Trevor Woerner <[email protected]>--- scripts/lib/devtool/deploy.py | 26 ++++++++++++++++++-------- 1 file changed, 18 insertions(+), 8 deletions(-)scripts/lib/devtool/deploy.py +18
-8@@ -169,11 +169,20 @@ def deploy(args, config, basepath, workspace): except Exception as e: raise DevtoolError('Exception parsing recipe %s: %s' % (args.recipename, e)) - recipe_outdir = rd.getVar('D') + if args.package: + recipe_outdir = os.path.join(rd.getVar('PKGDEST'), args.package) + else: + recipe_outdir = rd.getVar('D') if not os.path.exists(recipe_outdir) or not os.listdir(recipe_outdir): - raise DevtoolError('No files to deploy - have you built the %s ' - 'recipe? If so, the install step has not installed ' - 'any files.' % args.recipename) + if args.package: + raise DevtoolError('No files to deploy - have you built the %s ' + 'package of the %s recipe? If so, the install ' + 'step has not installed any files.' + % (args.package, args.recipename)) + else: + raise DevtoolError('No files to deploy - have you built the %s ' + 'recipe? If so, the install step has not installed ' + 'any files.' % args.recipename) if args.strip and not args.dry_run: # Fakeroot copy to new destination@@ -314,8 +323,8 @@ def register_commands(subparsers, context): """Register devtool subcommands from the deploy plugin""" parser_deploy = subparsers.add_parser('deploy-target', - help='Deploy recipe output files to live target machine', - description='Deploys a recipe\'s build output (i.e. the output of the do_install task) to a live target machine over ssh. By default, any existing files will be preserved instead of being overwritten and will be restored if you run devtool undeploy-target. Note: this only deploys the recipe itself and not any runtime dependencies, so it is assumed that those have been installed on the target beforehand.', + help='Deploy build output to a live target machine', + description='Deploys either the full recipe\'s build output (i.e. the output of the do_install task) or a package of a recipe to a live target machine over ssh. By default, any existing files will be preserved instead of being overwritten and will be restored if you run devtool undeploy-target. Note: this only deploys the specified item itself and not any runtime dependencies, so it is assumed that those have been installed on the target beforehand.', group='testbuild') parser_deploy.add_argument('recipename', help='Recipe to deploy') parser_deploy.add_argument('target', help='Live target machine running an ssh server: user@hostname[:destdir]')@@ -325,6 +334,7 @@ def register_commands(subparsers, context): parser_deploy.add_argument('-p', '--no-preserve', help='Do not preserve existing files', action='store_true') parser_deploy.add_argument('--no-check-space', help='Do not check for available space before deploying', action='store_true') parser_deploy.add_argument('-P', '--port', help='Specify port to use for connection to the target') + parser_deploy.add_argument('--package', help='Specify a recipe\'s package to deploy', dest='package') strip_opts = parser_deploy.add_mutually_exclusive_group(required=False) strip_opts.add_argument('-S', '--strip',@@ -337,8 +347,8 @@ def register_commands(subparsers, context): parser_deploy.set_defaults(func=deploy) parser_undeploy = subparsers.add_parser('undeploy-target', - help='Undeploy recipe output files in live target machine', - description='Un-deploys recipe output files previously deployed to a live target machine by devtool deploy-target.', + help='Undeploy output files from a live target machine', + description='Un-deploys output files previously deployed to a live target machine by devtool deploy-target.', group='testbuild') parser_undeploy.add_argument('recipename', help='Recipe to undeploy (if not using -a/--all)', nargs='?') parser_undeploy.add_argument('target', help='Live target machine running an ssh server: user@hostname')
Hi Khem,
Quoted 7 lines · Khem Raj
Quoted 1 line · Trevor Woerner
Instead of installing an entire recipe's build output (i.e. ${D}), allow
the
Quoted 3 lines
user to optionally specify a package from said recipe to be installed exclusively (i.e. ${PKGDEST}/<package>).
Quoted 6 lines
Thinking of developer's workflow, it might be needed to be able to install debug/dev packages to debug the package on device.
although I think we should be able to segment it and may be have an option to install the dev part separately
Currently -dev packages will be installed, but -dbg packages will not (since the components of the -dbg package aren't placed in ${D}). So if anything this patch (or better yet, the v2 I'll be sending shortly) will improve the situation.
Although I have noticed that there are differences between the -dbg package that is created with the normal bitbake workflow and the -dbg package that is created as part of the "devtool modify ..." workflow.