From: "Laszlo Ersek" <lersek@redhat.com>
To: Andrew Fish <afish@apple.com>
Cc: devel@edk2.groups.io, ray.ni@intel.com,
Mike Kinney <michael.d.kinney@intel.com>,
"Bi, Dandan" <dandan.bi@intel.com>,
"Cetola, Stephano" <stephano.cetola@intel.com>,
"Gao, Liming" <liming.gao@intel.com>,
"Carsey, Jaben" <jaben.carsey@intel.com>
Subject: Re: [edk2-devel] [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master
Date: Thu, 4 Apr 2019 18:06:49 +0200 [thread overview]
Message-ID: <6d7be3b2-c9c0-b543-ec49-e5b1701b2381@redhat.com> (raw)
In-Reply-To: <ABB0DEB6-D545-4DBB-958C-85595B9F4994@apple.com>
On 04/04/19 17:10, Andrew Fish wrote:
>
>
>> 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.
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
next prev parent reply other threads:[~2019-04-04 16:06 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-02 5:38 [RFC] Plan to delete ShellBinPkg from edk2/master Bi, Dandan
2019-04-02 8:49 ` Laszlo Ersek
2019-04-02 9:12 ` Leif Lindholm
2019-04-02 11:29 ` Ryszard Knop
2019-04-02 11:45 ` Laszlo Ersek
2019-04-02 11:50 ` Ryszard Knop
2019-04-02 12:56 ` Laszlo Ersek
2019-04-03 2:17 ` Ni, Ray
2019-04-03 10:09 ` Laszlo Ersek
2019-04-03 15:49 ` Kinney, Michael D
2019-04-03 16:07 ` Laszlo Ersek
2019-04-03 21:47 ` [edk2] " Michael D Kinney
2019-04-04 3:42 ` ray.ni
2019-04-04 4:09 ` [edk2-devel] " Andrew Fish
2019-04-04 10:45 ` Laszlo Ersek
2019-04-04 15:10 ` Andrew Fish
2019-04-04 16:06 ` Laszlo Ersek [this message]
2019-04-04 16:36 ` Andrew Fish
2019-04-08 8:08 ` Dandan Bi
2019-04-15 14:58 ` Liming Gao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6d7be3b2-c9c0-b543-ec49-e5b1701b2381@redhat.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox