From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Thu, 04 Apr 2019 09:06:54 -0700 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4998B307B483; Thu, 4 Apr 2019 16:06:54 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-122-229.rdu2.redhat.com [10.10.122.229]) by smtp.corp.redhat.com (Postfix) with ESMTP id 31C295D9C4; Thu, 4 Apr 2019 16:06:49 +0000 (UTC) Subject: Re: [edk2-devel] [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master To: Andrew Fish Cc: devel@edk2.groups.io, ray.ni@intel.com, Mike Kinney , "Bi, Dandan" , "Cetola, Stephano" , "Gao, Liming" , "Carsey, Jaben" References: <3C0D5C461C9E904E8F62152F6274C0BB40BB5D6F@SHSMSX104.ccr.corp.intel.com> <9492a5a0-58fc-4e49-4645-0593aa758660@redhat.com> <734D49CCEBEEF84792F5B80ED585239D5C0C69A2@SHSMSX104.ccr.corp.intel.com> <82ac9c41-e12d-7287-74f2-d8bea4516280@redhat.com> <565232dc-a0ff-7b1b-3a7c-9c6db0b26969@redhat.com> <734D49CCEBEEF84792F5B80ED585239D5C0CCA8C@SHSMSX104.ccr.corp.intel.com> <2c9dd2e2-c261-4216-9541-26f7e4a63988@redhat.com> From: "Laszlo Ersek" Message-ID: <6d7be3b2-c9c0-b543-ec49-e5b1701b2381@redhat.com> Date: Thu, 4 Apr 2019 18:06:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Thu, 04 Apr 2019 16:06:54 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit On 04/04/19 17:10, Andrew Fish wrote: > > >> On Apr 4, 2019, at 3:45 AM, Laszlo Ersek wrote: >> >> On 04/04/19 06:09, Andrew Fish wrote: >>> >>> >>>> On Apr 3, 2019, at 8:42 PM, Ni, Ray 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