Skip to contentSkip to conversation

package infra: add mirror support

PATCH New Gustavo Zacarias 7 participants 18 messages Oct 18, 2011 – Oct 19, 2011

lore
Share & tools
lore

Gustavo Zacarias

author
#0 lore raw

PATCH 1/2 package infra: add mirror support

Add FOO_MIRROR support for packages that have different URLs to fetch from, for redundancy or when they move to an obsolete/old directory when a new version pops up.
Only implement for WGET methods.

Signed-off-by Gustavo Zacarias <[email protected]>
---
 package/Makefile.package.in |   26 +++++++++++++++++++++++---
 1 files changed, 23 insertions(+), 3 deletions(-)
package/Makefile.package.in +23 -3
index b5ef57b..b9b5181 100644
@@ -207,10 +207,12 @@ endef
 # DOWNLOAD -- Download helper. Will try to download source from:
 # 1) BR2_PRIMARY_SITE if enabled
 # 2) Download site
-# 3) BR2_BACKUP_SITE if enabled
+# 3) Download mirror
+# 4) BR2_BACKUP_SITE if enabled
 #
 # Argument 1 is the source location
 # Argument 2 is the source filename
+# Argument 3 is the mirror location
 #
 # E.G. use like this:
 # $(call DOWNLOAD,$(FOO_SITE),$(FOO_SOURCE))

@@ -229,6 +231,15 @@ define DOWNLOAD
 			*) $(call $(DL_MODE)_WGET,$(1),$(2)) && exit ;; \
 		esac ; \
 	fi ; \
+	if test -n "$(3)" ; then \
+		case "$($(PKG)_SITE_METHOD)" in \
+			git) exit ;; \
+			svn) exit ;; \
+			bzr) exit ;; \
+			file) exit ;; \
+			*) $(call $(DL_MODE)_WGET,$(3),$(2)) && exit ;; \
+		esac ; \
+	fi ; \
 	if test -n "$(call qstrip,$(BR2_BACKUP_SITE))" ; then \
 		$(call $(DL_MODE)_WGET,$(BR2_BACKUP_SITE),$(2)) && exit ; \
 	fi ; \

@@ -266,8 +277,8 @@ ifeq ($(DL_MODE),DOWNLOAD)
 		(test -z $($(PKG)_PATCH) || test -e $(DL_DIR)$($(PKG)_PATCH))) || \
 		$(call MESSAGE,"Downloading")
 endif
-	$(if $($(PKG)_SOURCE),$(call DOWNLOAD,$($(PKG)_SITE),$($(PKG)_SOURCE)))
-	$(if $($(PKG)_PATCH),$(call DOWNLOAD,$($(PKG)_SITE),$($(PKG)_PATCH)))
+	$(if $($(PKG)_SOURCE),$(call DOWNLOAD,$($(PKG)_SITE),$($(PKG)_SOURCE),$($(PKG)_MIRROR)))
+	$(if $($(PKG)_PATCH),$(call DOWNLOAD,$($(PKG)_SITE),$($(PKG)_PATCH),$($(PKG)_MIRROR)))
 	$(foreach hook,$($(PKG)_POST_DOWNLOAD_HOOKS),$(call $(hook))$(sep))
 ifeq ($(DL_MODE),DOWNLOAD)
 	$(Q)mkdir -p $(@D)

@@ -463,6 +474,15 @@ ifndef $(2)_SITE
  endif
 endif
 
+ifndef $(2)_MIRROR
+ ifdef $(3)_MIRROR
+  $(2)_MIRROR = $($(3)_MIRROR)
+ else
+  $(2)_MIRROR			?= \
+	http://$$(BR2_SOURCEFORGE_MIRROR).dl.sourceforge.net/sourceforge/$(1)
+ endif
+endif
+
 ifndef $(2)_SITE_METHOD
  ifdef $(3)_SITE_METHOD
   $(2)_SITE_METHOD = $($(3)_SITE_METHOD)
Signature · 1 line
1.7.3.4
author
#1 lore raw

PATCH 2/2 stunnel: add mirror site

stunnel is known to move all but the latest version to an obsolete directory when there's a new release, as pointed out by Maxime Ripard.

Signed-off-by Gustavo Zacarias <[email protected]>
---
 package/stunnel/stunnel.mk |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
package/stunnel/stunnel.mk +1 -0
index 6088e58..c5ea152 100644
@@ -6,6 +6,7 @@
 
 STUNNEL_VERSION = 4.44
 STUNNEL_SITE = http://ftp.nluug.nl/pub/networking/stunnel
+STUNNEL_MIRROR = http://ftp.nluug.nl/pub/networking/stunnel/obsolete/4.x
 STUNNEL_DEPENDENCIES = openssl
 STUNNEL_CONF_OPT += \
 	--with-ssl=$(STAGING_DIR)/usr \
Signature · 1 line
1.7.3.4
#2 lore raw

PATCH 1/2 package infra: add mirror support

In reply to Gustavo Zacarias

Le Tue, 18 Oct 2011 11:14:54 -0300,
Gustavo Zacarias <[email protected]> a ?crit :

Quoted 4 lines

Add FOO_MIRROR support for packages that have different URLs to fetch from, for redundancy or when they move to an obsolete/old directory when a new version pops up.
Only implement for WGET methods.

Just wondering: what about making <pkg>_SITE a space-separated list of URLs to try, instead of adding <pkg>_MIRROR ?

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#3 lore raw

PATCH 1/2 package infra: add mirror support

In reply to Gustavo Zacarias

Le Tue, 18 Oct 2011 11:14:54 -0300,
Gustavo Zacarias <[email protected]> a ?crit :

package/Makefile.package.in define DOWNLOAD · line 239

Quoted 6 lines
package/Makefile.package.in +6 -0
+	if test -n "$(3)" ; then \
+		case "$($(PKG)_SITE_METHOD)" in \
+			git) exit ;; \
+			svn) exit ;; \
+			bzr) exit ;; \
+			file) exit ;; \

I don't think you want to exit here, you want to continue to evaluate the BR2_BACKUP_SITE solution below. For example, sources.buildroot.net has http://sources.buildroot.net/libsvgtiny-12121.tar.gz, which is the Subversion tarball of libsvgtiny. Same for
http://sources.buildroot.net/tslib-412d99d8b92c.tar.gz.

Regards,

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#4 lore raw

PATCH 1/2 package infra: add mirror support

Quoted 10 lines · Thomas Petazzoni

Le Tue, 18 Oct 2011 11:14:54 -0300,
Gustavo Zacarias <[email protected]> a ?crit :

package/Makefile.package.in define DOWNLOAD · line 239

Quoted 6 lines
package/Makefile.package.in +6 -0
+	if test -n "$(3)" ; then \
+		case "$($(PKG)_SITE_METHOD)" in \
+			git) exit ;; \
+			svn) exit ;; \
+			bzr) exit ;; \
+			file) exit ;; \

How about just a nop?
s/exit/:/

Mike

Quoted 9 lines

I don't think you want to exit here, you want to continue to evaluate the BR2_BACKUP_SITE solution below. For example, sources.buildroot.net has http://sources.buildroot.net/libsvgtiny-12121.tar.gz, which is the Subversion tarball of libsvgtiny. Same for
http://sources.buildroot.net/tslib-412d99d8b92c.tar.gz.

Regards,

Thomas

author
#5 lore raw

PATCH 1/2 package infra: add mirror support

Quoted 12 lines · Michael S. Zick
Quoted 10 lines · Thomas Petazzoni

Le Tue, 18 Oct 2011 11:14:54 -0300,
Gustavo Zacarias <[email protected]> a ?crit :

package/Makefile.package.in define DOWNLOAD · line 239

Quoted 6 lines
package/Makefile.package.in +6 -0
+	if test -n "$(3)" ; then \
+		case "$($(PKG)_SITE_METHOD)" in \
+			git) exit ;; \
+			svn) exit ;; \
+			bzr) exit ;; \
+			file) exit ;; \
Quoted 4 lines

How about just a nop?
s/exit/:/

Mike

Yes that's a solution.
I'm also looking into using multiple PKG_SITE definitions as Thomas suggested, however it's a bit more complicated since i've got to pull out the PKG_SITE_METHOD eval from GENTARGETS_INNER since we could have multiple methods for different mirrors.
That means looking that things don't break by doing so. Also contemplating how to properly do PKG_SIZE (for file size) and PKG_HASH (MD5 and/or SHA1) for source consistency.
Regards.

#6 lore raw

PATCH 1/2 package infra: add mirror support

Le Tue, 18 Oct 2011 13:00:28 -0300,
Gustavo Zacarias <[email protected]> a ?crit :

Quoted 2 lines

Also contemplating how to properly do PKG_SIZE (for file size) and PKG_HASH (MD5 and/or SHA1) for source consistency.

Do we actually want that ? I know OE does this, but tarball size and hashes will be a pain to keep updated.

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
author
#7 lore raw

PATCH 1/2 package infra: add mirror support

Quoted 10 lines · Thomas Petazzoni

Le Tue, 18 Oct 2011 13:00:28 -0300,
Gustavo Zacarias <[email protected]> a ?crit :

Quoted 2 lines

Also contemplating how to properly do PKG_SIZE (for file size) and PKG_HASH (MD5 and/or SHA1) for source consistency.

Do we actually want that ? I know OE does this, but tarball size and hashes will be a pain to keep updated.

Thomas

In a non-mandatory way it may be desirable.
That is if a package doesn't define it then we don't care. Most of the time tarballs shouldn't change size & hash, though it doesn't hold true for every project around.
It could also be an option to completely disable it. Regards.

#8 lore raw

PATCH 1/2 package infra: add mirror support

Quoted 11 lines · Gustavo Zacarias
Quoted 9 lines · Thomas Petazzoni

Le Tue, 18 Oct 2011 13:00:28 -0300,
Gustavo Zacarias <[email protected]> a ?crit :

Quoted 2 lines

Also contemplating how to properly do PKG_SIZE (for file size) and PKG_HASH (MD5 and/or SHA1) for source consistency.

Do we actually want that ? I know OE does this, but tarball size and hashes will be a pain to keep updated.

Quoted 6 lines
Quoted 1 line

Thomas

In a non-mandatory way it may be desirable.
That is if a package doesn't define it then we don't care. Most of the time tarballs shouldn't change size & hash, though it doesn't hold true for every project around.

Size and hash should only change when you bump the version, and in that case you anyway download the new tar file for testing so it shouldn't be too hard to recompute the hash. And of course, the hash should be the same regardless of which mirror it is downloaded from...

I'm not sure what good size would do, however.

Quoted 1 line

It could also be an option to completely disable it.

Definitely!

Regards,
Arnout

Signature · 6 lines
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
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:  31BB CF53 8660 6F88 345D  54CC A836 5879 20D7 CF43
#9 lore raw

[Buildroot] Adding hashes to package recipes

Le Tue, 18 Oct 2011 23:38:59 +0200,
Arnout Vandecappelle <[email protected]> a ?crit :

Quoted 4 lines

Size and hash should only change when you bump the version, and in
that case you anyway download the new tar file for testing so it shouldn't be too hard to recompute the hash. And of course, the hash should be the same regardless of which mirror it is downloaded from...

True, but what does it bring exactly ?

Quoted 3 lines
Quoted 1 line

It could also be an option to completely disable it.

Definitely!

Well, the check at runtime can be disabled, but the fact that there will be hashes in all packages to update every time we bump a package is not something that can be "disabled". I am not talking from an user point of view, but from a maintenance point of view.

I think in the past we talked about that with Peter and our opinions was that it wasn't worth it. Now, I guess that if there are sufficiently convincing arguments, we can change our minds :)

Regards,

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#10 lore raw

PATCH 1/2 package infra: add mirror support

In reply to Arnout Vandecappelle

Hi,

Quoted 6 lines · Arnout Vandecappelle
Quoted 4 lines

In a non-mandatory way it may be desirable.
That is if a package doesn't define it then we don't care. Most of the time tarballs shouldn't change size & hash, though it doesn't hold true for every project around.

Size and hash should only change when you bump the version

Unfortunately it is not so uncommon for some projects to re-release with the same version number if a bug sneaked into the released tarball. I know that this should not be the case, but it happens every so often.

Not sure though what implications this has for the proposed buildroot changes...

Regards,
Sven

#11 lore raw

PATCH 1/2 package infra: add mirror support

Quoted 7 lines · Sven Neumann
Quoted 5 lines · Arnout Vandecappelle
Quoted 4 lines

In a non-mandatory way it may be desirable.
That is if a package doesn't define it then we don't care. Most of the time tarballs shouldn't change size & hash, though it doesn't hold true for every project around.

Quoted 8 lines
Quoted 1 line

Size and hash should only change when you bump the version

Unfortunately it is not so uncommon for some projects to re-release with the same version number if a bug sneaked into the released tarball. I know that this should not be the case, but it happens every so often.

Not sure though what implications this has for the proposed buildroot changes...

I guess that if we start with this feature, it should be limited to
warnings for the first year or so until it proves its worth.

The recent kernel.org horror has convinced me that some form of
verification is needed, though.

Regards,
Arnout

Signature · 6 lines
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
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:  31BB CF53 8660 6F88 345D  54CC A836 5879 20D7 CF43
#12 lore raw

PATCH 1/2 package infra: add mirror support

Le Wed, 19 Oct 2011 11:35:52 +0200,
Arnout Vandecappelle <[email protected]> a ?crit :

Quoted 2 lines

The recent kernel.org horror has convinced me that some form of
verification is needed, though.

Having hashes in Buildroot will not necessarily provide an additional security. Consider the following scenario:

1. The world exists.
2. Project foo releases foo-2.1.tar.bz2
3. A BR packager bumps package foo to 2.1. He downloads the new tarball, generates locally its hash and adds this hash to the foo.mk.
4. The BR packager patch is merged in Buildroot.

Having hashes in the foo.mk will warn you if the foo website has been cracked after step 3. But if it has been cracked between 2) and 3), then you're doomed: the BR packager will assume foo-2.1.tar.bz2 is correct. This packager will quite probably never check a GPG signature or do any kind of additional security check when bumping foo to 2.1.

Therefore, I fear that this mechanism would give an *impression* of higher security, but would in fact provide no additional security compared to not verifying the hashes.

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#13 lore raw

PATCH 1/2 package infra: add mirror support

Quoted 11 lines · Thomas Petazzoni

Le Wed, 19 Oct 2011 11:35:52 +0200,
Arnout Vandecappelle <[email protected]> a ?crit :

Quoted 2 lines

The recent kernel.org horror has convinced me that some form of
verification is needed, though.

Having hashes in Buildroot will not necessarily provide an additional security. Consider the following scenario:

1. The world exists.

Thomas, I can hardly keep myself from typing a smart remark here. ;-)

Quoted 6 lines

2. Project foo releases foo-2.1.tar.bz2
3. A BR packager bumps package foo to 2.1. He downloads the new tarball, generates locally its hash and adds this hash to the foo.mk.
4. The BR packager patch is merged in Buildroot.

Quoted 6 lines

Having hashes in the foo.mk will warn you if the foo website has been cracked after step 3. But if it has been cracked between 2) and 3), then you're doomed: the BR packager will assume foo-2.1.tar.bz2 is correct. This packager will quite probably never check a GPG signature or do any kind of additional security check when bumping foo to 2.1.

In my local, subjective, reality (#1) - - -

I post for re-distribution on one of my web sites archives built by others (who don't provide signatures or even checksums).

When I post a package, I include the original posting link, a checksum and a signature file.
But all that I can claim is that "if the signature matches, you have got a true copy of what I posted" - which doesn't make any claims that what I got was "correct" or the "intended" original.

From my server logs, it appears that it is an usual event for someone to download either the signature or the checksum.
So in practice, it seems that few people bother to check.

Quoted 4 lines

Therefore, I fear that this mechanism would give an *impression* of higher security, but would in fact provide no additional security compared to not verifying the hashes.

When done further down the line of distribution than the original creator of the package during package creation time...

It does give the "subjective impression" (see #1) that the poster was following some sort of "best practices" in their re-distribution; A "good thing".

But I have to agree that it also gives the impression that the contents are still as the original packager intended;
Which could be a "bad thing".
For instance:
When troubleshooting a problem, having passed this "warm and fuzzy test" it might be a long time before the user suspects that something is wrong inside of the "trusted" package contents.

Add to the fact that few even bother to check...
I don't think it is worth the time and trouble to __add__ checksums and signatures;
Although it would be a benefit to also archive any checksums and signatures provided by the __original__ package creator.

Mike

Quoted 1 line

Thomas

#14 lore raw

PATCH 1/2 package infra: add mirror support

In reply to Thomas Petazzoni

Hi,

Le 19/10/2011 14:59, Thomas Petazzoni a ?crit :

Quoted 20 lines

Le Wed, 19 Oct 2011 11:35:52 +0200, Arnout Vandecappelle<[email protected]> a ?crit :

Quoted 2 lines

The recent kernel.org horror has convinced me that some form of verification is needed, though.

Having hashes in Buildroot will not necessarily provide an additional security. Consider the following scenario:

1. The world exists. 2. Project foo releases foo-2.1.tar.bz2 3. A BR packager bumps package foo to 2.1. He downloads the new tarball, generates locally its hash and adds this hash to the foo.mk. 4. The BR packager patch is merged in Buildroot.

Having hashes in the foo.mk will warn you if the foo website has been cracked after step 3. But if it has been cracked between 2) and 3), then you're doomed: the BR packager will assume foo-2.1.tar.bz2 is correct. This packager will quite probably never check a GPG signature or do any kind of additional security check when bumping foo to 2.1.

Quoted 4 lines

Therefore, I fear that this mechanism would give an *impression* of higher security, but would in fact provide no additional security compared to not verifying the hashes.

apart from security, the hash feature gives the user the opportunity to be sure that he is using the sources which were used by the initial package creator and thus are the one which are supposed to have been validated at least once.
This can be useful when projects are changing the source archive without changing the version number (example : qt 4.7.4 archive which was regenerated after the first release) or for project where the source archive with a version number is a symbolic link to a source archive with an other version number (example : binutils x.y.z which is now x.y.za).
Without a hash check you won't notice these changes (and thus can't analyse the impact they may have on your build).

Eric

#15 lore raw

PATCH 1/2 package infra: add mirror support

In reply to Thomas Petazzoni
Quoted 16 lines · Thomas Petazzoni

Le Wed, 19 Oct 2011 11:35:52 +0200,
Arnout Vandecappelle <[email protected]> a ?crit :

Quoted 2 lines

The recent kernel.org horror has convinced me that some form of
verification is needed, though.

Having hashes in Buildroot will not necessarily provide an additional security. Consider the following scenario:

1. The world exists.
2. Project foo releases foo-2.1.tar.bz2
3. A BR packager bumps package foo to 2.1. He downloads the new tarball, generates locally its hash and adds this hash to the foo.mk.
4. The BR packager patch is merged in Buildroot.

Quoted 4 lines

Having hashes in the foo.mk will warn you if the foo website has been cracked after step 3. But if it has been cracked between 2) and 3), then you're doomed: the BR packager will assume foo-2.1.tar.bz2 is correct.

If the upstream source is cracked, then of course you're doomed. What it does protect again is man-in-the-middle attacks (same as https is supposed to protect against but doesn't because of unreliable CAs). If the packager generates a hash of a non-authorized tar, then most users will download packages with a different hash and will (hopefully) report this.

Clearly there is still a vulnerability window, but it is much smaller than in the current situation.

Quoted 6 lines

This packager will quite probably never check a GPG signature or do any kind of additional security check when bumping foo to 2.1.

Therefore, I fear that this mechanism would give an *impression* of higher security, but would in fact provide no additional security compared to not verifying the hashes.

It does give higher security. Perhaps not yet high security, though.

Regards,
Arnout

Signature · 6 lines
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
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:  31BB CF53 8660 6F88 345D  54CC A836 5879 20D7 CF43
#16 lore raw

PATCH 1/2 package infra: add mirror support

In reply to Michael S. Zick

Mike, All,

Quoted 12 lines · On Tuesday 18 October 2011 17:55:20 Michael S. Zick wrote:
Quoted 10 lines · Thomas Petazzoni

Le Tue, 18 Oct 2011 11:14:54 -0300,
Gustavo Zacarias <[email protected]> a ?crit :

package/Makefile.package.in define DOWNLOAD · line 239

Quoted 6 lines
package/Makefile.package.in +6 -0
+	if test -n "$(3)" ; then \
+		case "$($(PKG)_SITE_METHOD)" in \
+			git) exit ;; \
+			svn) exit ;; \
+			bzr) exit ;; \
+			file) exit ;; \
Quoted 2 lines

How about just a nop?
s/exit/:/

Or simply:
foo) ;;

Regards,
Yann E. MORIN.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
#17 lore raw

PATCH 1/2 package infra: add mirror support

In reply to Gustavo Zacarias
Quoted 19 lines · Gustavo Zacarias

Add FOO_MIRROR support for packages that have different URLs to fetch from, for redundancy or when they move to an obsolete/old directory when a new version pops up.
Only implement for WGET methods.

Signed-off-by Gustavo Zacarias <[email protected]>
---
 package/Makefile.package.in |   26 +++++++++++++++++++++++---
 1 files changed, 23 insertions(+), 3 deletions(-)
package/Makefile.package.in +0 -0
index b5ef57b..b9b5181 100644
@@ -207,10 +207,12 @@ endef
 
 # DOWNLOAD -- Download helper. Will try to download source from:
 # 1) BR2_PRIMARY_SITE if enabled
 # 2) Download site

package/Makefile.package.in endef · line 215

Quoted 10 lines
package/Makefile.package.in +3 -1
 
-# 3) BR2_BACKUP_SITE if enabled
+# 3) Download mirror
+# 4) BR2_BACKUP_SITE if enabled
 
 #
 # Argument 1 is the source location
 # Argument 2 is the source filename
 
+# Argument 3 is the mirror location

Argument 3 will be $($(PKG)_MIRROR) in all calls, so there is no need to
make it an argument. Just use $($(PKG)_MIRROR) directly, like it is done for $($(PKG)_SITE_METHOD).

package/Makefile.package.in define DOWNLOAD · line 234

Quoted 9 lines

#
# E.G. use like this:
# $(call DOWNLOAD,$(FOO_SITE),$(FOO_SOURCE))

package/Makefile.package.in +1 -0
@@ -229,6 +231,15 @@ define DOWNLOAD
 			*) $(call $(DL_MODE)_WGET,$(1),$(2)) && exit ;; \
 		esac ; \
 	fi ; \
+	if test -n "$(3)" ; then \

You can easily support $($(PKG)_MIRRORS) (plural) with
for mirror in $($(PKG)_MIRRORS); do \
... $$mirror ...
done

This will simply skip the loop if $(3) is empty.

package/Makefile.package.in define DOWNLOAD · line 241

Quoted 7 lines
package/Makefile.package.in +7 -0
+		case "$($(PKG)_SITE_METHOD)" in \
+			git) exit ;; \
+			svn) exit ;; \
+			bzr) exit ;; \
+			file) exit ;; \
+			*) $(call $(DL_MODE)_WGET,$(3),$(2)) && exit ;; \
+		esac ; \

Is there a need to check for $($(PKG)_SITE_METHOD) at all? This is not
done for the BR2_BACKUP_SITE after all.

Quoted 16 lines
package/Makefile.package.in +3 -2
+	fi ; \
 	if test -n "$(call qstrip,$(BR2_BACKUP_SITE))" ; then \
 		$(call $(DL_MODE)_WGET,$(BR2_BACKUP_SITE),$(2)) && exit ; \
 	fi ; \

@@ -266,8 +277,8 @@ ifeq ($(DL_MODE),DOWNLOAD)
 		(test -z $($(PKG)_PATCH) || test -e $(DL_DIR)$($(PKG)_PATCH))) || \
 		$(call MESSAGE,"Downloading")
 endif
-	$(if $($(PKG)_SOURCE),$(call DOWNLOAD,$($(PKG)_SITE),$($(PKG)_SOURCE)))
-	$(if $($(PKG)_PATCH),$(call DOWNLOAD,$($(PKG)_SITE),$($(PKG)_PATCH)))
+	$(if $($(PKG)_SOURCE),$(call DOWNLOAD,$($(PKG)_SITE),$($(PKG)_SOURCE),$($(PKG)_MIRROR)))
+	$(if $($(PKG)_PATCH),$(call DOWNLOAD,$($(PKG)_SITE),$($(PKG)_PATCH),$($(PKG)_MIRROR)))
 	$(foreach hook,$($(PKG)_POST_DOWNLOAD_HOOKS),$(call $(hook))$(sep))
 ifeq ($(DL_MODE),DOWNLOAD)
 	$(Q)mkdir -p $(@D)

package/Makefile.package.in ifndef $(2)_SITE · line 482

Quoted 9 lines
package/Makefile.package.in +6 -0
@@ -463,6 +474,15 @@ ifndef $(2)_SITE
  endif
 endif
 
+ifndef $(2)_MIRROR
+ ifdef $(3)_MIRROR
+  $(2)_MIRROR = $($(3)_MIRROR)
+ else
+  $(2)_MIRROR			?= \
+	http://$$(BR2_SOURCEFORGE_MIRROR).dl.sourceforge.net/sourceforge/$(1)

Err... Either it is a sourceforge package and then this will already be the
normal URL, or it is not and then this will just fail. Or am I missing something?

package/Makefile.package.in ifndef $(2)_SITE · line 488

Quoted 7 lines
package/Makefile.package.in +3 -0
+ endif
+endif
+
 ifndef $(2)_SITE_METHOD
  ifdef $(3)_SITE_METHOD
   $(2)_SITE_METHOD = $($(3)_SITE_METHOD)

Regards,
Arnout

Signature · 6 lines
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
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:  31BB CF53 8660 6F88 345D  54CC A836 5879 20D7 CF43