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) 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