On Fri, Jun 1, 2018 at 7:58 AM, Trevor Woerner <twoer...@gmail.com> wrote:
> 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?
Right. The list of packages to blacklist by default would need some
thought and it's probably more than just the -dev package.
> 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.
> 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.
>> >> 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
