I do not think that expanding shellPkg would work since there is no requirement that any of these apps depend on it. As was stated, MicroPythonPkg does not.
I also do not think that moving ShellPkg makes lots of sense since it is used by many platforms. -Jaben > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ni, > Ruiyu > Sent: Thursday, November 29, 2018 7:40 PM > To: krishnaLee <sssky...@163.com>; Kinney, Michael D > <michael.d.kin...@intel.com> > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] [RFC] Proposal to add edk2-apps repository > Importance: High > > Krishna, > The reason there are applications inside MdeModulePkg/Application is that > the shell protocol was in ShellPkg when the app was developed and > MdeModulePkg cannot depend on ShellPkg (rule). > Now since shell protocol is moved to MdePkg, any apps can depend on shell > protocol. (In fact they wanted to but just wasn't allowed due to reason > above.) > > I even prefer to move the ShellPkg to the edk2-app repo Mike proposed. > Instead of enlarge the ShellPkg:) > > I don't prefer edk2-libc unless we have a strategy/plan to make ordinary C > developer easy by promoting the std-c pkg. > The other reason I prefer edk2-app is then ShellPkg might be moved to that > new repo. > > > > -----Original Message----- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > > krishnaLee > > Sent: Friday, November 30, 2018 9:45 AM > > To: edk2-devel@lists.01.org > > Subject: Re: [edk2] [RFC] Proposal to add edk2-apps repository > > > > Kinney, > > I always think there may be two kinds of apps: > > 1,some apps have dependency on uefi_shell(shell- > lib,efi_shell_protocol,...they > > usually execute under uefi_shell),I would call them > "uefi_shell_application"; > > 2,some apps have no dependency on uefi_shell(such as apps in > > MdeModulePkg/Application),I would call them > "standard_uefi_application". > > > > The "AppPkg / StdLib / StdLibPrivateInternalFiles" packages are usually > used by > > uefi_shell_application,I think they can all move to ShellPkg,no need to > create > > new package ? > > > > > > Thanks, > > krishna. > > > > At 2018-11-30 08:46:58, "Kinney, Michael D" <michael.d.kin...@intel.com> > > wrote: > > >Leif, > > > > > >I did consider the edk2-libc name. The port of Python 2.7 is in the > > >AppPkg as well and it uses libc. > > > > > >So the content of this new package is a combination of libc And apps > > >that use libc. > > > > > >I am definitely open to alternate names. 2 options so far: > > > > > >* edk2-apps > > >* edk2-libc > > > > > >Thanks, > > > > > >Mike > > > > > >> -----Original Message----- > > >> From: Leif Lindholm [mailto:leif.lindh...@linaro.org] > > >> Sent: Thursday, November 29, 2018 2:41 PM > > >> To: Kinney, Michael D <michael.d.kin...@intel.com> > > >> Cc: edk2-devel@lists.01.org > > >> Subject: Re: [edk2] [RFC] Proposal to add edk2-apps repository > > >> > > >> On Thu, Nov 29, 2018 at 05:58:08PM +0000, Kinney, Michael D wrote: > > >> > Hello, > > >> > > > >> > I would like to propose the creation of a new repository called > > >> > edk2-apps. This repository would initially be used to host the > > >> > following packages from the edk2 repository: > > >> > > > >> > * AppPkg > > >> > * StdLib > > >> > * StdLibPrivateInternalFiles > > >> > > >> Let me start by saying I 100% back moving these out of the main edk2 > > >> repository. > > >> > > >> > 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-apps repository and add it to PACKAGES_PATH. > > >> > > >> I must confess to never having properly understood the scope of > > >> AppPkg to begin with. > > >> > > >> AppPkg/Applications/Hello does not appear to have any further (real) > > >> dependency on libc than MdeModulePkg/Application/HelloWorld/, and > . > > >> > > >> And certainly MdeModulePkg/Applications contain plenty of ... > > >> applications. > > >> > > >> So, if the purpose is simply to provide some examples of application > > >> written to libc rather than UEFI - should this be edk2- libc instead? > > >> > > >> Best Regards, > > >> > > >> Leif > > >> > > >> > The history of these 3 packages would be preserved when importing > > >> > the content into edk2-apps. 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. > > >> > > > >> > Best regards, > > >> > > > >> > Mike > > >> > _______________________________________________ > > >> > edk2-devel mailing list > > >> > edk2-devel@lists.01.org > > >> > https://lists.01.org/mailman/listinfo/edk2-devel > > >_______________________________________________ > > >edk2-devel mailing list > > >edk2-devel@lists.01.org > > >https://lists.01.org/mailman/listinfo/edk2-devel > > _______________________________________________ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
