[PATCH] kernel: Clean DEPLOYDIR before do_deploy runs

[PATCH] kernel: Clean DEPLOYDIR before do_deploy runs

[Richard Purdie]

If we don't do this, the deploy sstate object contains an every
increasing number of modules tarballs and kernel images, one per
execution of "-c deploy -f".

Cleaning the directory before we start makes things much tidier.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index dee6f7d..f37affc 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -511,6 +511,7 @@ kernel_do_deploy() {
 		ln -sf ${initramfs_base_name}.bin ${initramfs_symlink_name}.bin
 	fi
 }
+do_deploy[cleandirs] = "${DEPLOYDIR}"
 do_deploy[dirs] = "${DEPLOYDIR} ${B}"
 do_deploy[prefuncs] += "package_get_auto_pr"
 

Re: [PATCH] kernel: Clean DEPLOYDIR before do_deploy runs

[Bruce Ashfield]

On 2016-01-25 10:07 AM, Richard Purdie wrote:
> If we don't do this, the deploy sstate object contains an every
> increasing number of modules tarballs and kernel images, one per
> execution of "-c deploy -f".
>

Stupid question, since my sstate/deploy foo is weak at times.
Does this mean that only a single set of modules + kernel images
will be in tmp/deploy ? Or is it only sstate that is being
cleaned ?

I sometimes need multiple copies around for debug purposes, so
I'm wondering if that is still possible with this change ?

Bruce

> Cleaning the directory before we start makes things much tidier.
>
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index dee6f7d..f37affc 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -511,6 +511,7 @@ kernel_do_deploy() {
>   		ln -sf ${initramfs_base_name}.bin ${initramfs_symlink_name}.bin
>   	fi
>   }
> +do_deploy[cleandirs] = "${DEPLOYDIR}"
>   do_deploy[dirs] = "${DEPLOYDIR} ${B}"
>   do_deploy[prefuncs] += "package_get_auto_pr"
>
>
>

Re: [PATCH] kernel: Clean DEPLOYDIR before do_deploy runs

[Richard Purdie]

On Mon, 2016-01-25 at 10:47 -0500, Bruce Ashfield wrote:
> On 2016-01-25 10:07 AM, Richard Purdie wrote:
> > If we don't do this, the deploy sstate object contains an every
> > increasing number of modules tarballs and kernel images, one per
> > execution of "-c deploy -f".
> > 
> 
> Stupid question, since my sstate/deploy foo is weak at times.
> Does this mean that only a single set of modules + kernel images
> will be in tmp/deploy ? Or is it only sstate that is being
> cleaned ?

One side effect is that it will remove the older copies. The older
copies were being built into each new sstate object which was growing
huge.

> I sometimes need multiple copies around for debug purposes, so
> I'm wondering if that is still possible with this change ?

You'd need to archive them before running another build since this
effectively cleans up the older copies now. This is due to the system
removing the old sstate "object", then installing a new one to replace
it. You can't keep the old ones around easily as they're named to
conflict (and hence replace each other).

Cheers,

Richard

Re: [PATCH] kernel: Clean DEPLOYDIR before do_deploy runs

[Bruce Ashfield]

On 2016-01-25 10:52 AM, Richard Purdie wrote:
> On Mon, 2016-01-25 at 10:47 -0500, Bruce Ashfield wrote:
>> On 2016-01-25 10:07 AM, Richard Purdie wrote:
>>> If we don't do this, the deploy sstate object contains an every
>>> increasing number of modules tarballs and kernel images, one per
>>> execution of "-c deploy -f".
>>>
>>
>> Stupid question, since my sstate/deploy foo is weak at times.
>> Does this mean that only a single set of modules + kernel images
>> will be in tmp/deploy ? Or is it only sstate that is being
>> cleaned ?
>
> One side effect is that it will remove the older copies. The older
> copies were being built into each new sstate object which was growing
> huge.
>
>> I sometimes need multiple copies around for debug purposes, so
>> I'm wondering if that is still possible with this change ?
>
> You'd need to archive them before running another build since this
> effectively cleans up the older copies now. This is due to the system
> removing the old sstate "object", then installing a new one to replace
> it. You can't keep the old ones around easily as they're named to
> conflict (and hence replace each other).

Ack'd. I'll have to remember to copy out what I need! :)

Bruce

>
> Cheers,
>
> Richard
>