[OE-core] [devtool][PATCH] devtool deploy-target: optionally specify package

[Paul Eggleton]

Hi Trevor,

On Friday, 1 June 2018 2:23:59 PM NZST Trevor Woerner wrote:
> 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.

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.

> 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


-- 

Paul Eggleton
Intel Open Source Technology Centre