On Apr 4, 2019, at 3:45 AM, Laszlo Ersek <lersek@redhat.com> wrote:

On 04/04/19 06:09, Andrew Fish wrote:

On Apr 3, 2019, at 8:42 PM, Ni, Ray <ray.ni@intel.com> wrote:

Mike, Laszlo,
It's a good idea to store the shell binaries into the assets of each stable tag.

If we go in this way, it means "build" requires network connection to download the
shell binary from the assets of a certain release.
Do you think it's acceptable?

Ray,

The other option would be to have a configuration step, like installing Python or the C compilers, that copies the binary. You need a network connection to clone the git repo and to stay in sync with it. I guess you could model that as a git submodule, or actually have a script that grabs the binary you want from a remote system, and fall back to the local copy if you don't have a network connection. 

Or we can separate the binary download and build into two phases so build phase
can be independent on network connection.

Is there any known practice/solution for such requirement (stable sub-component binaries
needed by a production image generation)?

I think to some extent this kind of thing is driven by the customers build rules. Basically what the customer think of as their manifest of parts for software version X.

I suggested PREBUILD because I took it as a given, from Mike's problem
statement, that "build" had to ensure, internally, the local
availability of the shell binary.

If that's a not requirement, then IMO it's much better to leave it to
organizations to fetch the prerequisites of their platform builds. I'd
say that's out of scope for upstream edk2 -- if they need the shell
binary to be available off-line, at their build time, they can download
it earlier and cache it locally.

Thanks
Laszlo