[Buildroot] [PATCH 0/4] pkg-infra: differentiate remote and local tarball filenames (branch yem/download)
Thomas Petazzoni
thomas.petazzoni at free-electrons.com
Sun Nov 16 11:22:10 UTC 2014
Dear Yann E. MORIN,
On Sat, 15 Nov 2014 17:19:24 +0100, Yann E. MORIN wrote:
> This series introduces a new variable, FOO_UPSTREAM_SOURCE, so as to be
> able to differentiate remote and local tarball filenames.
>
> This is needed when upstream tarballs are not named the way we expect them
> to be. For example, the GitHub API only provides a request like:
> GET /repos/:owner/:repo/:archive_format/:ref
>
> So far, we're not using this API, and directly use a non-stable scheme
> to retrieve the tarballs. That scheme has proven to break from time to
> time, so we'll soon need to switch to the API, which is guaranteed to be
> stable.
>
> So, we need to be able to differentiate the filename remote knows the
> tarball by, and the local filename we want to save that tarball as.
>
> Changes to the GitHub helper will come in a later series, because it is
> a bit more involved, and still needs some ironing out. Alternate forges
> may also get added in the future, which would require such a feature.
Not directly related, but somewhat related: I have always though that
our split between <foo>_SITE and <foo>_SOURCE was a bit stupid. Why
don't we simply give a full URL instead of splitting that between SITE
and SOURCE ?
The way we do things today also forces the things in <foo>_PATCH and
<foo>_EXTRA_DOWNLOADS to be under the exact same <foo>_SITE, which
prevents applying patches from other locations than the original
package site.
Shouldn't we simply get rid of <pkg>_SITE, and make <pkg>_SOURCE the
full URL to the tarball / git repo?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
More information about the buildroot
mailing list