On Thu, May 31, 2018 at 11:07 PM, Andre McCurdy <armccu...@gmail.com> wrote:
> On Thu, May 31, 2018 at 7:23 PM, Trevor Woerner <twoer...@gmail.com>
> 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?
> >> 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?).
>
> 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?
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
