[1/2] pkg-download: add optional destination filename

This adds an optional parameter to the DOWNLOAD macro so that it's
possible to specify a destination filename that's different from one
being downloaded.

Signed-off-by: Frank Hunleth <fhunleth@troodon-software.com>
---
 package/pkg-download.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

On 19/04/15 18:57, Frank Hunleth wrote:
> This adds an optional parameter to the DOWNLOAD macro so that it's
> possible to specify a destination filename that's different from one
> being downloaded.

 In this case, this filename should be used instead of the upstream filename
when downloading from PRIMARY or SECONDARY.

 And perhaps for the time being both should be tried, because current caches
still have the old filenames...

 Regards,
 Arnout

> 
> Signed-off-by: Frank Hunleth <fhunleth@troodon-software.com>
> ---
>  package/pkg-download.mk | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/package/pkg-download.mk b/package/pkg-download.mk
> index e274712..1278018 100644
> --- a/package/pkg-download.mk
> +++ b/package/pkg-download.mk
> @@ -244,13 +244,14 @@ endef
>  # 3) BR2_BACKUP_SITE if enabled, unless BR2_PRIMARY_SITE_ONLY is set
>  #
>  # Argument 1 is the source location
> +# Argument 2 is an optional destination filename
>  #
>  # E.G. use like this:
>  # $(call DOWNLOAD,$(FOO_SITE))
>  ################################################################################
>  
>  define DOWNLOAD
> -	$(call DOWNLOAD_INNER,$(1),$(notdir $(1)))
> +	$(call DOWNLOAD_INNER,$(1),$(if $(2),$(2),$(notdir $(1))))
>  endef
>  
>  define DOWNLOAD_INNER
>

Dear Frank Hunleth,

On Sun, 19 Apr 2015 12:57:58 -0400, Frank Hunleth wrote:
> This adds an optional parameter to the DOWNLOAD macro so that it's
> possible to specify a destination filename that's different from one
> being downloaded.
> 
> Signed-off-by: Frank Hunleth <fhunleth@troodon-software.com>
> ---
>  package/pkg-download.mk | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

This patch is still pending in patchwork, but the discussion in PATCH
2/2 didn't really reached a conclusion other than the fact that you had
a very specific case of a patch being updated by upstream without being
renamed, and that you were going to talk with upstream about this. We
haven't heard from you about this specific problem since end of April,
and anyway the proposed implementation wasn't matching our requirements.

So I've marked this patch as Rejected in patchwork. Of course, if you
still have the issue, let's reopen the discussion and work on a proper
solution for the problem.

Thanks!

Thomas

Hi Thomas,

On Tue, Jul 14, 2015 at 6:39 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
> Dear Frank Hunleth,
>
> On Sun, 19 Apr 2015 12:57:58 -0400, Frank Hunleth wrote:
> > This adds an optional parameter to the DOWNLOAD macro so that it's
> > possible to specify a destination filename that's different from one
> > being downloaded.
> >
> > Signed-off-by: Frank Hunleth <fhunleth@troodon-software.com>
> > ---
> >  package/pkg-download.mk | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
>
> This patch is still pending in patchwork, but the discussion in PATCH
> 2/2 didn't really reached a conclusion other than the fact that you had
> a very specific case of a patch being updated by upstream without being
> renamed, and that you were going to talk with upstream about this. We
> haven't heard from you about this specific problem since end of April,
> and anyway the proposed implementation wasn't matching our requirements.
>
> So I've marked this patch as Rejected in patchwork. Of course, if you
> still have the issue, let's reopen the discussion and work on a proper
> solution for the problem.

Yes, this is the right answer. Thanks for closing the loop.

To summarize what happened between then and now, I traded messages
with people on the Intel Edison mailing list, but the responses took
about as long as my project. The change to maintain the kernel and
uboot sources outside of their massive Yocto tar ball is on their
"roadmap". That would get rid of the patch file naming conflicts that
started this whole patch series.

For me, I ended up copying the uboot and kernel patches to the local
BR tree for the project. Since I'm finished with the work on the
Edison, I don't have a need for the patch anymore. However, if others
run into issues with getting Buildroot to work on the Edison, I don't
mind digging up my notes and sharing.

Thanks,
Frank