From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCHv5 1/9] support/download: reintroduce 'source-check' target
Date: Wed, 27 Mar 2019 17:35:48 +0100 [thread overview]
Message-ID: <20190327173548.7db271b5@windsurf> (raw)
In-Reply-To: <69fd8276-ea53-75a5-240a-a0e146cd8b62@mind.be>
Hello,
Thanks a lot for sharing your feedback in this discussion, it's very
useful.
On Wed, 27 Mar 2019 14:46:32 +0100
Arnout Vandecappelle <arnout@mind.be> wrote:
> For the use case of Thomas DS, this weak semantic is perfectly fine. What it
> tries to protect against is the common mistake that you add or bump a package
> and forget to upload the source to PRIMARY_SITE. As explained by Thomas DS,
> doing a full download is eventually still needed, but takes much longer:
> source-check may take in the order of 1 minute while the full download takes 10
> minutes. That makes all the difference for immediate feedback to the developer,
> and it doesn't significantly slow down a good pipeline.
>
> Indeed, it does not protect against uploading the wrong tarball with the
> correct name. It also doesn't protect against forgetting to update the hash
> file. It also doesn't protect against the package failing to build. It also
> doesn't protect against bugs in the code which become only apparent at run time.
> But all of these are checked later in CI, and the source check captures an
> important (and likely) class of mistakes early on.
Interesting perspective indeed :-)
> It is true that this is a very narrow use case. However, I think it passes two
> tests for acceptance:
>
> * It does not make Buildroot (much) more complex.
>
> * There is no way to do this with scripting outside of Buildroot.
True.
> Regarding that second point: in fact there would be a way, if we would instead
> have a command to print everything that would be downloaded. That would be very
> similar to patch 1/9, but would remove the need for the other patches in the
> series. The advantage of this approach is that there could be other uses for
> printing the list of sources. But that would be back to the drawing board for
> Thomas DS, so I doubt he's enthusiastic about that option :-) Plus, we have no
> actual example of an additional use case.
We already have "make external-deps" but it only prints the file names,
not the full URL.
Does Thomas really want to check the BR2_PRIMARY_SITE or the original
Mercurial repository ? If he wants to check BR2_PRIMARY_SITE (which
contains only tarballs), then he could run "make external-deps" and
checks that the tarballs are here. But I suppose that's not what Thomas
wants: he really wants to check the upstream Mercurial repository, no?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2019-03-27 16:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-19 10:38 [Buildroot] [PATCHv5 1/9] support/download: reintroduce 'source-check' target Thomas De Schampheleire
2019-02-19 10:38 ` [Buildroot] [PATCHv5 2/9] support/download/hg: implement source-check Thomas De Schampheleire
2019-02-19 10:38 ` [Buildroot] [PATCHv5 3/9] support/download/wget: " Thomas De Schampheleire
2019-02-19 10:38 ` [Buildroot] [PATCHv5 4/9] support/download/file: " Thomas De Schampheleire
2019-02-19 10:38 ` [Buildroot] [PATCHv5 5/9] Revert "core/download: drop the SSH command" Thomas De Schampheleire
2019-02-19 10:38 ` [Buildroot] [PATCHv5 6/9] package/pkg-download: export 'SSH' for use in the download backends Thomas De Schampheleire
2019-02-19 10:38 ` [Buildroot] [PATCHv5 7/9] support/download/scp: implement source-check Thomas De Schampheleire
2019-02-19 10:38 ` [Buildroot] [PATCHv5 8/9] support/download/svn: " Thomas De Schampheleire
2019-02-19 10:38 ` [Buildroot] [PATCHv5 9/9] support/download/{bzr, cvs, git}: highlight unimplemented source-check Thomas De Schampheleire
2019-03-17 14:32 ` [Buildroot] [PATCHv5 1/9] support/download: reintroduce 'source-check' target Yann E. MORIN
2019-03-17 14:57 ` Thomas Petazzoni
2019-03-27 13:46 ` Arnout Vandecappelle
2019-03-27 14:13 ` Thomas De Schampheleire
2019-03-27 16:35 ` Thomas Petazzoni [this message]
2019-03-27 17:25 ` Arnout Vandecappelle
2019-04-13 15:24 ` Arnout Vandecappelle
2019-04-13 15:51 ` Thomas De Schampheleire
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=20190327173548.7db271b5@windsurf \
--to=thomas.petazzoni@bootlin.com \
--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.