[Task] Update to nasm 3 and move the nasm feed

[makubacki]

Until now, edk2 has had a NuGet dependency on nasm from the following location: https://www.nuget.org/packages/mu_nasm

The feed has not been actively maintained since then. To get a maintained version of the nasm dependency with bug fixes in 2.16.01, the following feed is used at the moment: https://dev.azure.com/projectmu/mu/_artifacts/feed/Basetools-Binary/NuGet/mu_nasm

It would be preferable if:

1. NuGet was not used
2. The feed consumed in edk2 is under Tianocore ownership

This issue tracks:

1. Moving the nasm dependency to a different technology than NuGet
2. Hosting the dependency under infrastructure in Tianocore
3. Placing the latest nasm release - https://www.nasm.us/docs/3.01/nasmac.html

[mikebeaton]

Note that nasm and iasl (acpica-tools) are already included using dnf in CI build images
https://github.com/tianocore/containers/blob/main/Fedora-41/Dockerfile
https://github.com/tianocore/containers/blob/main/Fedora-43/Dockerfile
and are also available from apt in Ubuntu, and I believe chocolately in Windows.

CI on the current ARM image runs perfectly (with warnings during stuart setup) using these versions. (EDIT: Actually, I'm not sure if this is working because I am manually symlinking these to where stuart wants them to come from, but either way, it works just fine.)

Do we definitely need a separate distribution for stuart?

[makubacki]

Do we definitely need a separate distribution for stuart?

The supported stuart external dependency types are here.

---

The general requirements tend to be:

• A trusted source - No malicious software with virus scanning, etc.
• Reliable - Does not impact edk2 builds because of down time
• Reproducible - The exact version used at any time in an edk2 build is accessible in the future

For Linux, the edk2 community has historically preferred maintaining their own local installation. It's open to feedback, but I think using the container for CI/local with the option to maintain nasm locally is acceptable. I think this comes down to the experience on Linux when not using a container.

On Windows, we need an automated solution that works in the stuart environment. One issue with some managers like Chocolatey is that they have different editions with different features some of which are useful for automation and not available in the free edition. They also usually require admin privilege which we want to avoid requiring for firmware builds. So, a simple, small, download of the portable executable works well.

---

To meet those requirements with the least coordination, we've typically built code from source, packaged it, and pushed it to an owned feed. To keep the experience for dependency management as consistent as possible across different environments (from a project management perspective), stuart has been used to get dependencies.

That's why the most natural next step is to mostly retain this model with the goals defined in the issue. But I don't think we're strictly constrained to that.

[mikebeaton]

I think this comes down to the experience on Linux when not using a container.

For this, if the container becomes the source of truth for correct versions for official builds, but for non-container builds maybe stuart could even have a new 'Local install' dependency type, where it reports on the required package (useful for iasl), or just simply says that a local install is required without helping out with the dnf/apt package name, then this could work?

On Windows, we need an automated solution that works in the stuart environment. One issue with some managers like Chocolatey is that they have different editions with different features some of which are useful for automation and not available in the free edition. They also usually require admin privilege which we want to avoid requiring for firmware builds. So, a simple, small, download of the portable executable works well.

For this - less simple. Unless the pre-packaged dependency types can be upgraded with a config flag to say that local install is allowed? So you still get Windows versions from the maintained package, but not Unix versions, where it will prompt to say that a local install is required?

[makubacki]

I think this comes down to the experience on Linux when not using a container.

For this, if the container becomes the source of truth for correct versions for official builds, but for non-container builds maybe stuart could even have a new 'Local install' dependency type, where it reports on the required package (useful for iasl), or just simply says that a local install is required without helping out with the dnf/apt package name, then this could work?

That's along the line that I'm thinking as well.

On Windows, we need an automated solution that works in the stuart environment. One issue with some managers like Chocolatey is that they have different editions with different features some of which are useful for automation and not available in the free edition. They also usually require admin privilege which we want to avoid requiring for firmware builds. So, a simple, small, download of the portable executable works well.

For this - less simple. Unless the pre-packaged dependency types can be upgraded with a config flag to say that local install is allowed? So you still get Windows versions from the maintained package, but not Unix versions, where it will prompt to say that a local install is required?

Something like that sounds reasonable as well.

---

Due to the community consensus needed for something more disruptive, I focused this issue on some less intricate steps in the right direction - such as using Universal Packages which have better Linux support than NuGet and are already supported as an ext dep in stuart, alongside moving the feed under Tianocore ownership to make it easier to maintain by the community, and pushing the nasm update while at it.

---

If you'd like to propose any specific solutions for stuart, an issue or discussion in the edk2-pytool-extensions repo would be a good place to get feedback.