Patchwork scripts: apply-patches: don't stop if no patch is found for a package

login
register
mail settings
Submitter Andi Shyti
Date Nov. 5, 2013, 1 p.m.
Message ID <1383656430-29160-1-git-send-email-andi@etezian.org>
Download mbox | patch
Permalink /patch/288498/
State Superseded
Headers show

Comments

Andi Shyti - Nov. 5, 2013, 1 p.m.
If no patch is available for a specific package it doesn't mean
that is necessarily an error, perhaps there is no need to apply
any patches. Therefore, don't stop the build by returning '1',
but go ahead.

Signed-off-by: Andi Shyti <andi@etezian.org>
---
 support/scripts/apply-patches.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Arnout Vandecappelle - Nov. 5, 2013, 6:51 p.m.
On 05/11/13 14:00, Andi Shyti wrote:
> If no patch is available for a specific package it doesn't mean
> that is necessarily an error, perhaps there is no need to apply
> any patches. Therefore, don't stop the build by returning '1',
> but go ahead.

  This is in fact intentional, because it indicates that there is 
something wrong with the configuration. When you specify in your 
configuration that some specific patch directory should be used, but that 
directory doesn't exist, then it probably means you made a mistake in 
your configuration.

  Can you give an example of a specific situation where you had a problem 
with this check?

  Regards,
  Arnout

>
> Signed-off-by: Andi Shyti <andi@etezian.org>
> ---
>   support/scripts/apply-patches.sh | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/support/scripts/apply-patches.sh b/support/scripts/apply-patches.sh
> index ff72b45..aabab4f 100755
> --- a/support/scripts/apply-patches.sh
> +++ b/support/scripts/apply-patches.sh
> @@ -43,7 +43,7 @@ if [ ! -d "${builddir}" ] ; then
>   fi
>   if [ ! -d "${patchdir}" ] ; then
>       echo "Aborting.  '${patchdir}' is not a directory."
> -    exit 1
> +    exit
>   fi
>
>   # Remove any rejects present BEFORE patching - Because if there are
>
Andi Shyti - Nov. 5, 2013, 8:17 p.m.
Hi Arnout,

> >If no patch is available for a specific package it doesn't mean
> >that is necessarily an error, perhaps there is no need to apply
> >any patches. Therefore, don't stop the build by returning '1',
> >but go ahead.
> 
>  This is in fact intentional, because it indicates that there is
> something wrong with the configuration. When you specify in your
> configuration that some specific patch directory should be used, but
> that directory doesn't exist, then it probably means you made a
> mistake in your configuration.
> 
>  Can you give an example of a specific situation where you had a
> problem with this check?

this happens when for example you want to get as cross compiler
the daily snapshot instead of a specific version.

The build stops with an error because of that 'exit 1' since it
doesn't find any gcc-20131105 patch directory (i think the
snapshot is called so).

Andi
Arnout Vandecappelle - Nov. 6, 2013, 9:32 p.m.
On 05/11/13 21:17, Andi Shyti wrote:
> Hi Arnout,
>
>>> If no patch is available for a specific package it doesn't mean
>>> that is necessarily an error, perhaps there is no need to apply
>>> any patches. Therefore, don't stop the build by returning '1',
>>> but go ahead.
>>
>>   This is in fact intentional, because it indicates that there is
>> something wrong with the configuration. When you specify in your
>> configuration that some specific patch directory should be used, but
>> that directory doesn't exist, then it probably means you made a
>> mistake in your configuration.
>>
>>   Can you give an example of a specific situation where you had a
>> problem with this check?
>
> this happens when for example you want to get as cross compiler
> the daily snapshot instead of a specific version.
>
> The build stops with an error because of that 'exit 1' since it
> doesn't find any gcc-20131105 patch directory (i think the
> snapshot is called so).

  That's a bug in the gcc package then :-)

  It should actually be converted to using the default patch strategy 
instead of post-patch hooks. Let me look into it...


  Regards,
  Arnout
Thomas Petazzoni - Nov. 6, 2013, 10:16 p.m.
Dear Arnout Vandecappelle,

On Wed, 06 Nov 2013 22:32:58 +0100, Arnout Vandecappelle wrote:

>   That's a bug in the gcc package then :-)
> 
>   It should actually be converted to using the default patch strategy 
> instead of post-patch hooks. Let me look into it...

Good luck. The gcc package is special: there is only one location for
the gcc patches (i.e package/gcc/<version>/), but there are in fact
three gcc packages (package/gcc/gcc-{initial,intermediate,final}).

I'm impatient to see what your solution will be :-)

Thomas

Patch

diff --git a/support/scripts/apply-patches.sh b/support/scripts/apply-patches.sh
index ff72b45..aabab4f 100755
--- a/support/scripts/apply-patches.sh
+++ b/support/scripts/apply-patches.sh
@@ -43,7 +43,7 @@  if [ ! -d "${builddir}" ] ; then
 fi
 if [ ! -d "${patchdir}" ] ; then
     echo "Aborting.  '${patchdir}' is not a directory."
-    exit 1
+    exit
 fi
 
 # Remove any rejects present BEFORE patching - Because if there are