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