All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] Different site methods for the main package and patches
Date: Wed, 26 Mar 2014 18:46:16 +0100	[thread overview]
Message-ID: <53331268.4030205@mind.be> (raw)
In-Reply-To: <CA+-urNQrPff3iTDGdWwYvbhLPXwCrqZgVA91qQS_RgM66VG1eQ@mail.gmail.com>

On 24/03/14 01:47, Frank Hunleth wrote:
> I've run into an issue where I'd like to retrieve a package using git
> and then patch it using a diff file from another site. In my case, the
> package is the Linux kernel.
> 
> This is possible to reproduce using the raspberrypi_defconfig and
> adding the BR2_LINUX_KERNEL_PATCH line below. Here are the relevant
> lines:
> 
> BR2_LINUX_KERNEL=y
> BR2_LINUX_KERNEL_CUSTOM_GIT=y
> BR2_LINUX_KERNEL_CUSTOM_REPO_URL="git://github.com/raspberrypi/linux.git"
> BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="3bff11d4d4b8dc28cb9ce81449c989466ba27198"
> BR2_LINUX_KERNEL_PATCH="http://download.filesystems.org/unionfs/unionfs-2.x-latest/unionfs-2.5.12_for_3.10.21.diff.gz"
> 
> The call that fails is in package/pkg-download.mk in DOWNLOAD_INNER.
> There's a test whether LINUX_SITE_METHOD is defined (which it is) and
> to use it for the $scheme. This is correct to download the kernel, but
> incorrect when going through the kernel patches. If I could undefine
> LINUX_SITE_METHOD, my use case would work since the method would be
> determined via the URI, but obviously other use cases would break.
> 
> For patches, I'd almost think that the <package>_SITE_METHOD shouldn't
> be used at all, since multiple patches could be specified that come
> from different places. I don't know what the ramifications of that
> change would be, though, or if there's a simpler solution.

 You're probably right about that. The problem is that the DOWNLOAD macro
cannot know if it is given a patch or the package itself. So it should
probably be changed to get _SITE_METHOD as an optional argument.

 Yann, perhaps you could take that up into your download method rework
series?

 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

  reply	other threads:[~2014-03-26 17:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-24  0:47 [Buildroot] Different site methods for the main package and patches Frank Hunleth
2014-03-26 17:46 ` Arnout Vandecappelle [this message]
2014-03-26 22:37   ` Thomas Petazzoni
2014-03-26 22:42     ` Peter Korsgaard
2014-03-26 23:00       ` rjbarnet at rockwellcollins.com
2014-03-26 23:26       ` Thomas Petazzoni
2014-03-26 23:34         ` Peter Korsgaard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53331268.4030205@mind.be \
    --to=arnout@mind.be \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.