Re: [edk2-devel] [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master

["Andrew Fish" <afish@apple.com>]

[-- Attachment #1: Type: text/plain, Size: 2764 bytes --]



> 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. 

Thanks,

Andrew Fish


> Thanks
> Laszlo


[-- Attachment #2: Type: text/html, Size: 12856 bytes --]