From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=QHltwhS0; spf=pass (domain: apple.com, ip: 17.151.62.68, mailfrom: afish@apple.com) Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) by groups.io with SMTP; Thu, 04 Apr 2019 08:11:56 -0700 Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id x34F71NH010360; Thu, 4 Apr 2019 08:11:55 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=jib5M/qMJeFH63wcQ/M1ici6rM1eAcyfvdhMgIUgMeU=; b=QHltwhS0mN7h1aNwlgmFLbopx4VtK9nZ23zqQHVckZKRsyP+w4nW1yrG2e/frtXu4HGY 3gAQwA0YzaL5RU86/2Eub9pyC8pMc8xaRMjVwKsMLE9NZB9gO60rZ/tOdeXcDlM8CfLS rFU03/S99k/KPGwd3Su6lpxRp43o67QIePn/K+NbnCn1Wjk/4px3HQW6hXJ40kx34Jb1 EBuAJjDOU8vw8NNMUlj1lB/fTBm1FrIx0vmQ3gFH6mMkT18C23+3ufNjbD2vURpNaLIB BEL3tBYWiDYAP9ZHH+/qUWXkvdy16IzsgUhg9db0I1BQ03fPiFHER2MywPKeOwOazga3 5Q== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2rmg2mr1yy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 04 Apr 2019 08:11:55 -0700 MIME-version: 1.0 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PPF0002IZJTYH50@ma1-mtap-s02.corp.apple.com>; Thu, 04 Apr 2019 08:11:54 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PPF00H00ZJORI00@nwk-mmpp-sz10.apple.com>; Thu, 04 Apr 2019 08:11:53 -0700 (PDT) X-Va-A: X-Va-T-CD: 07a9f7dd315dc6000695a0402a47d12d X-Va-E-CD: d9b9ad8de82c93238b5cb6235c180f11 X-Va-R-CD: 1ab40ac838417d3a6569c88ce1c44cd5 X-Va-CD: 0 X-Va-ID: 0a957b39-1dd0-4bff-875f-ca9ef92647a1 X-V-A: X-V-T-CD: 13715775cfe6ed78bc954dbcb503dbb2 X-V-E-CD: d9b9ad8de82c93238b5cb6235c180f11 X-V-R-CD: 1ab40ac838417d3a6569c88ce1c44cd5 X-V-CD: 0 X-V-ID: 46e488ce-8027-44cc-8674-8610939e325b X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-04-04_07:,, signatures=0 Received: from [17.234.110.230] (unknown [17.234.110.230]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PPF00LFCZHG7M00@nwk-mmpp-sz10.apple.com>; Thu, 04 Apr 2019 08:10:29 -0700 (PDT) Sender: afish@apple.com From: "Andrew Fish" Message-id: Subject: Re: [edk2-devel] [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master Date: Thu, 04 Apr 2019 08:10:25 -0700 In-reply-to: <2c9dd2e2-c261-4216-9541-26f7e4a63988@redhat.com> Cc: devel@edk2.groups.io, ray.ni@intel.com, Mike Kinney , "Bi, Dandan" , "Cetola, Stephano" , "Gao, Liming" , "Carsey, Jaben" To: Laszlo Ersek 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> X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-04-04_07:,, signatures=0 Content-type: multipart/alternative; boundary="Boundary_(ID_2XofcE/j4iqDMykZjhmufw)" --Boundary_(ID_2XofcE/j4iqDMykZjhmufw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > 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. Thanks, Andrew Fish > Thanks > Laszlo --Boundary_(ID_2XofcE/j4iqDMykZjhmufw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable

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

= --Boundary_(ID_2XofcE/j4iqDMykZjhmufw)--