[Buildroot] Github URL used to fetch packages

[Buildroot] Github URL used to fetch packages

[Maxime Hadjinlian]

Hi everyone,

Buildroot is currently using this method to get packages from Github:
http://buildroot.uclibc.org/downloads/manual/manual.html#github-download-url

As you may know, Github released a feature called "Release" which
basically, create a tag for you and associate that tag with a zip and
a tarball, example:
https://github.com/nandra/libiqrf/releases

This doesn't change much with the URL we use to grab the package.

Current : http://github.com/<user>/<package>/tarball/$(FOO_VERSION)
Release: http://github.com/<user>/<package>/archive/$(FOO_VERSION)

With the second one, FOO_VERSION is the tag name (which can be
anything, it's a string, that's all the constraints on it).

Github supports both way so everything is great, nothing is broken.
But if they stop allowing the uses of our current way, we would have
to change one bit of the URL for ALL the packages. Which is a pain.

Github has already changed the way to fetch package in the past and
deprecated the old method, and this might happen over and over.

What about a way to standardize the way to grab package from github, like:
github://<user>/<package>/$(FOO_VERSION)

We could then expand the URL to whatever is the best way of fetching
the packages.

This would be a good way for Buildroot to prevent breakage would a
provider such as Github changes the way to fetch data.

[Buildroot] Github URL used to fetch packages

[Arnout Vandecappelle]

On 30/10/13 10:53, Maxime Hadjinlian wrote:
> Hi everyone,
>
> Buildroot is currently using this method to get packages from Github:
> http://buildroot.uclibc.org/downloads/manual/manual.html#github-download-url
>
> As you may know, Github released a feature called "Release" which
> basically, create a tag for you and associate that tag with a zip and
> a tarball, example:
> https://github.com/nandra/libiqrf/releases
>
> This doesn't change much with the URL we use to grab the package.
>
> Current : http://github.com/<user>/<package>/tarball/$(FOO_VERSION)
> Release: http://github.com/<user>/<package>/archive/$(FOO_VERSION)
>
> With the second one, FOO_VERSION is the tag name (which can be
> anything, it's a string, that's all the constraints on it).
>
> Github supports both way so everything is great, nothing is broken.
> But if they stop allowing the uses of our current way, we would have
> to change one bit of the URL for ALL the packages. Which is a pain.
>
> Github has already changed the way to fetch package in the past and
> deprecated the old method, and this might happen over and over.
>
> What about a way to standardize the way to grab package from github, like:
> github://<user>/<package>/$(FOO_VERSION)
>
> We could then expand the URL to whatever is the best way of fetching
> the packages.
>
> This would be a good way for Buildroot to prevent breakage would a
> provider such as Github changes the way to fetch data.

  I like the idea. We would typically do this with some auxiliary 
variables instead of a new download method, but maybe the download method 
isn't such a bad idea. It would add even more complexity to the horrible 
pkg-download.mk, though...

  Bottom line: the idea is good, but let's see if the implementation can 
be acceptable.

  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

[Buildroot] Github URL used to fetch packages

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Mon, 04 Nov 2013 08:10:07 +0100, Arnout Vandecappelle wrote:

>   I like the idea. We would typically do this with some auxiliary 
> variables instead of a new download method, but maybe the download method 
> isn't such a bad idea. It would add even more complexity to the horrible 
> pkg-download.mk, though...
> 
>   Bottom line: the idea is good, but let's see if the implementation can 
> be acceptable.

Instead of a new download method, can it simply be a helper function,
like:

FOO_SITE = $(call github,<user>,<package>,<version>)

or something like that. This way we don't clutter the core of the
download infrastructure with another site method that isn't really a
site method.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Github URL used to fetch packages

[Thomas De Schampheleire]

Hi,

On Mon, Nov 4, 2013 at 9:26 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Arnout Vandecappelle,
>
> On Mon, 04 Nov 2013 08:10:07 +0100, Arnout Vandecappelle wrote:
>
>>   I like the idea. We would typically do this with some auxiliary
>> variables instead of a new download method, but maybe the download method
>> isn't such a bad idea. It would add even more complexity to the horrible
>> pkg-download.mk, though...
>>
>>   Bottom line: the idea is good, but let's see if the implementation can
>> be acceptable.
>
> Instead of a new download method, can it simply be a helper function,
> like:
>
> FOO_SITE = $(call github,<user>,<package>,<version>)
>
> or something like that. This way we don't clutter the core of the
> download infrastructure with another site method that isn't really a
> site method.

I'm ok with this suggestion.

Best regards,
Thomas

[Buildroot] Github URL used to fetch packages

[Samuel Martin]

All,


2013/11/4 Thomas De Schampheleire <patrickdepinguin@gmail.com>

> Hi,
>
> On Mon, Nov 4, 2013 at 9:26 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > Dear Arnout Vandecappelle,
> >
> > On Mon, 04 Nov 2013 08:10:07 +0100, Arnout Vandecappelle wrote:
> >
> >>   I like the idea. We would typically do this with some auxiliary
> >> variables instead of a new download method, but maybe the download
> method
> >> isn't such a bad idea. It would add even more complexity to the horrible
> >> pkg-download.mk, though...
> >>
> >>   Bottom line: the idea is good, but let's see if the implementation can
> >> be acceptable.
> >
> > Instead of a new download method, can it simply be a helper function,
> > like:
> >
> > FOO_SITE = $(call github,<user>,<package>,<version>)
> >
> > or something like that. This way we don't clutter the core of the
> > download infrastructure with another site method that isn't really a
> > site method.
>
> I'm ok with this suggestion.
>

I like this too.

Regards,

-- 
Samuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20131104/979d44f3/attachment.html>