Re: [RFC v2] Proposal to add edk2-libc

[Laszlo Ersek <lersek@redhat.com>]

On 01/16/19 19:57, Kinney, Michael D wrote:
> Hello,
> 
> I shared an RFC in November to add an edk2-apps repository.
> 
> https://lists.01.org/pipermail/edk2-devel/2018-November/033330.html
> 
> Feedback in this thread discussed that there are three types
> of applications.  Apps that use libc, UEFI Shell apps,
> and UEFI Applications.  I would like this RFC to focus on libc
> applications, and changes related to UEFI Shell apps and
> UEFI Applications can be handled separately.  The updated
> RFC is shown below.  The repo name has been changed from
> edk2-apps to edk2-libc based on feedback from Leif.
> 
> ============================================================
> 
> I would like to propose the creation of a new
> repository called edk2-libc.  This repository
> would initially be used to host the following
> packages from the edk2 repository:
> 
> * AppPkg
> * StdLib
> * StdLibPrivateInternalFiles
> 
> These 3 packages provide support for the libc along
> with applications that depend on libc.  None of the
> other packages in the edk2 repository use these
> packages, so these 3 package can be safely moved
> without any impacts to platform firmware builds.
> Build configurations that do use libc features can
> clone the edk2-libc repository and add it to
> PACKAGES_PATH.
> 
> The history of these 3 packages would be preserved
> when importing the content into edk2-libc.  After
> the import is verified, these 3 packages would be
> deleted from the edk2 repository.
> 
> This proposal helps reduce the size of the edk2
> repository and focuses edk2 repository on packages
> used to provide UEFI/PI conformant firmware.
> 
> If there are no concerns with this proposal, I will
> enter a Tianocore BZs for the two steps.

It sounds good to me:

- PACKAGES_PATH is a useful feature and it works well in my experience,
so I think having to use PACKAGES_PATH for pulling in edk2-libc should
not be a large obstacle.

- I'm not sure how closely the StdLib internals are tied to day-to-day
changes in core edk2; that is, whether we should keep those histories
interlinked. That's something for the StdLib maintainers to evaluate.
Personally I don't remember many StdLib changes, so there seems to be a
genuine separation that supports the new repo idea.

Thanks,
Laszlo