> On Apr 4, 2019, at 9:06 AM, Laszlo Ersek <ler...@redhat.com> wrote: > > On 04/04/19 17:10, Andrew Fish wrote: >> >> >>> On Apr 4, 2019, at 3:45 AM, Laszlo Ersek <ler...@redhat.com> wrote: >>> >>> On 04/04/19 06:09, Andrew Fish wrote: >>>> >>>> >>>>> On Apr 3, 2019, at 8:42 PM, Ni, Ray <ray...@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 > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#73): https://edk2.groups.io/g/devel/message/73 Mute This Topic: https://groups.io/mt/30886118/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
