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). Thanks, Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#71): https://edk2.groups.io/g/devel/message/71 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] -=-=-=-=-=-=-=-=-=-=-=-
