From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] Github URL used to fetch packages
Date: Mon, 04 Nov 2013 08:10:07 +0100 [thread overview]
Message-ID: <5277484F.4070402@mind.be> (raw)
In-Reply-To: <CAGduivwP_AykQSnspeAWqSxxNbMRLwRja_h0BDLYRX3scmDCTQ@mail.gmail.com>
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
next prev parent reply other threads:[~2013-11-04 7:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-30 9:53 [Buildroot] Github URL used to fetch packages Maxime Hadjinlian
2013-11-04 7:10 ` Arnout Vandecappelle [this message]
2013-11-04 8:26 ` Thomas Petazzoni
2013-11-04 8:28 ` Thomas De Schampheleire
2013-11-04 9:31 ` Samuel Martin
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=5277484F.4070402@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.