All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Korsgaard <peter@korsgaard.com>
To: <yann.morin@orange.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH] package/pkg-download: do not try to vendor _EXTRA_DOWNLOADS
Date: Sat, 28 May 2022 11:00:47 +0200	[thread overview]
Message-ID: <87h75ac9q8.fsf@dell.be.48ers.dk> (raw)
In-Reply-To: <24588_1651771186_62740732_24588_360_1_2d4cd3ac6995d7b5119ef4dfdc22b975992b8a73.1651770627.git.yann.morin@orange.com> (yann morin's message of "Thu, 5 May 2022 19:19:39 +0200")

>>>>>   <yann.morin@orange.com> writes:

 > From: "Yann E. MORIN" <yann.morin@orange.com>
 > For golang- or cargo-based packages, we apply a vendoring pass after the
 > package's "main" download is done. Whether to vendor or not is based on
 > the heuristic that a specific directory exists or not; for golang
 > packages, we look for '/vendor', while for cargo, we look for '/VENDOR'.

 > This is fine for the "main" (by lack of a better term) download, but
 > this falls flat on its face for extra downloads. Indeed, so packages may
 > need to download data sets, or assets, as _EXTRA_DOWNLOADS. Those are
 > usually just data blobs, and are not actual golang or cargo packages; as
 > such they do not need to be vendored, but worse, if we try to actually
 > vendor them, this fails because the required files for vendoring are
 > missing from the archives in such data sets.

 > We fix that by decoupling the download for the extra download, from the
 > download for the main archive. We pass the post-processing option only
 > to the main download.

 > This makes the hard assumption that extra downloads will never need to
 > be post-processed for vendoring, of course; we hope this will always be
 > correct in practice.

 > Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
 > Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

Committed to 2022.02.x, thanks.

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

      parent reply	other threads:[~2022-05-28  9:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-05 17:19 [Buildroot] [PATCH] package/pkg-download: do not try to vendor _EXTRA_DOWNLOADS yann.morin
2022-05-05 20:37 ` Arnout Vandecappelle
2022-05-06  5:21   ` yann.morin
2022-05-10 19:24     ` Arnout Vandecappelle
2022-05-11  6:00       ` yann.morin
2022-05-28  9:00 ` Peter Korsgaard [this message]

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=87h75ac9q8.fsf@dell.be.48ers.dk \
    --to=peter@korsgaard.com \
    --cc=buildroot@buildroot.org \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=yann.morin@orange.com \
    /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.