Ard:

  I see IA32/X64 Shell binary has been updated for 201903 stable tag. But, ARM/ARCH64 version shell binary is not updated. Could you upload new version binaries? Then, I can upload them into 2019 stable tag Assets.

Thanks

Liming

From: Bi, Dandan
Sent: Monday, April 8, 2019 4:08 PM
To: afish@apple.com; devel@edk2.groups.io; Laszlo Ersek <lersek@redhat.com>
Cc: Ni, Ray <ray.ni@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Cetola, Stephano <stephano.cetola@intel.com>; Gao, Liming <liming.gao@intel.com>; Carsey, Jaben <jaben.carsey@intel.com>; Bi, Dandan <dandan.bi@intel.com>
Subject: RE: [edk2-devel] [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master

Thanks Andrew for the summary.

For now there is no objection for platform to use shell source build, so I think I can remove the dependency of ShellBinPkg in all open platforms firstly.

And I will delete ShellBinPkg if there is no need to publish shell binaries or after shell binaries have been uploaded with stable tag.

If all think publish stable shell binaries is useful and need to upload them with stable tag.

Liming,  could you help work out the process for shell binaries publish with each edk2 stable tag?

Then we can follow the process to upload the binaries and remove ShellBinPkg finally.

Thanks,

Dandan

From: afish@apple.com [mailto:afish@apple.com]
Sent: Friday, April 5, 2019 12:36 AM
To: devel@edk2.groups.io; Laszlo Ersek <lersek@redhat.com>
Cc: Ni, Ray <ray.ni@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Bi, Dandan <dandan.bi@intel.com>; Cetola, Stephano <stephano.cetola@intel.com>; Gao, Liming <liming.gao@intel.com>; Carsey, Jaben <jaben.carsey@intel.com>
Subject: Re: [edk2-devel] [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master

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

On 04/04/19 17:10, Andrew Fish wrote:

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.

Laszlo,

I guess for edk2 projects the maintainers own the manifest. So the edk2 projects that need the Shell should define how that works. I don't think we need to define a generic solution for 3rd parties as I'd guess Red Hat and Microsoft probably already have tools and strategies to deal with cobbling together software from different packages.  

So I guess we should ask the maintainers of the ekd2 packages does the version of the Shell matter? If no then just pre-install a shell binary as part of the setup. If the version matters then we should look into doing something a little more fancy, and use the pre-installed shell binary as the fallback.

Is there anyway to tell the Shell version from the Shell PE/COFF? One option could be a build warning if the shell is old and just have the user manually update the shell if needed.

As a co-maintainer under OvmfPkg and ArmVirtPkg, I prefer to build the
shell from source at all times, namely from the source code that is part
of the entire edk2 tree at a given commit / checkout.

I don't see any possibility or desire for the virtual firmware packages
(RPMs) that I have a say in to consume/ship a pre-built UEFI shell binary.

--*--

The reason I recommend for us (the TianoCore community) to offer the
shell as a prebuilt binary too, somewhere on the web, is because it
would help UEFI users (in the most general sense).

Laszlo,

Sorry I might have taken the discussion off the rails. 

1) It seems like that for edk2 folks are happy with build form source. 

2)I agree it would useful to have a known good binary that people can download from the web, and the hash that proves it is the version you think it is. Some instructions on how build a bootable USB key would be useful too. 

3) We don't really need to solve the problem of a build system and binaries if non of the edk2 packages require that feature. 

Thanks,

Andrew Fish

Thanks,
Laszlo