Re: [edk2-devel] OvmfPkg PlatformCI: Should iasl dependency be updated from 20190215.0.0 ?

["Sean" <spbrogan@outlook.com>]

[-- Attachment #1: Type: text/plain, Size: 3202 bytes --]


On 5/3/2023 10:56 PM, Gerd Hoffmann wrote:
>    Hi,
>
>> I agree the iasl dependency for CI has not been managed consistently.   When
>> all of the CI was setup we decided that iasl should be controlled by the
>> platform and thus EmulatorPkg, ArmVirt, and OVMF have their own extdep.
>> This gives those platforms control to rev their version as necessary for
>> their platform.   We have found it very common in platform development for
>> platforms to have different required versions of iasl.exe.
> Are there cases where /old/ iasl versions are required?

Yes.  On the commercial PC side we see this a lot.  Given how much ASL 
is in modern PCs it is very common for a platform's ASL code to not 
compile with the latest version.  That product and by extension, the ASL 
code, is often supported for 5+ years and then if you add on that the 
ASL compiler was probably already a year old at initial release that 
means the compiler can often be pretty old.  Additionally for those 
building brand new products that are using new capabilities in ACPI, 
they often need the newest version and can't wait for the distro package 
repository to pick up.  As a outsider/consumer of Linux, we have 
definitely had pain caused by the distro's default/available version.  
For the Edk2 repo I can remember a lot of challenges around python 2 and 
3 and versions and the various distro's package management.

Additionally, for CI we want to drive consistency between Windows and 
Linux.  We want visibility into versions used and reproducibility.   
Depending on distro package management make this significantly harder.

EmulatorPkg, ArmVirtPkg, and OVMF could all opt into using the "scope" 
(edk2/Readme.md at master · tianocore/edk2 · GitHub 
<https://github.com/tianocore/edk2/blob/master/.pytool/Readme.md#pytool-scopes>) 
that would leverage the Core CI's version of iasl so that they don't 
need to manage this but my initial hope was to showcase this capability 
and allow those "platforms" some of their own autonomy.  Obviously they 
haven't needed or used that yet so as we update Core CI we could also 
update those platforms to follow with the same extdep and version.

>
>> As for the feed.  Yes they are inconsistent.   We were moving away from a
>> global nuget.org feed as it just didn't seem necessary to push to
>> nuget.org.  But now we are evaluating ways to move entirely away from
>> nuget.  Nuget.exe worked pretty well for Windows development and our initial
>> use cases but has definitely created a headache on Linux, MacOS and other.
>> There really isn't a generic package management solution that is supported
>> cross platform that has free/high quality/secure hosting.  If anyone has
>> ideas please share.
> On linux / macos / *bsd there is usually no need to create your own
> package management.  Standard stuff like iasl / nasm is available as
> linux distro package / bsd ports collection package.
>
> Usually you can't pick specific versions.  Usually this isn't a big
> issue though, unless you are using an older distro (such as ubuntu 18.04
> we used for CI before switching to containers) and need a recent version.
>
> take care,
>    Gerd
>

[-- Attachment #2: Type: text/html, Size: 4270 bytes --]