Figure out what to do about installers that can only be built in specific containers

[mmitche]

There are some assets (deb and rpm bits) that are built in specific containers. Up till this point, the plan has been to divide up the verticals based on the existing runtime legs, and invoke a build command for each one. This should then produce all outputs required to ship .NET. How do we handle deb and rpm packages in this case? The runtime build usually invokes builds of those packages in separate containers. This is less desirable as it uses AzDO tasks to accomplish this, meaning you'd have to exit the build and re-enter.

What should be done here?

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[mmitche]

@ViktorHofer @hoyosjs @wtgodbe

[jkoritzinsky]

If we do the following items, we can remove the requirement for separate containers to build Linux packages.

• Update sdk to use new Arcade .deb creation tooling sdk#43688

• Update aspnetcore to use new Arcade .deb creation tooling aspnetcore#58073

• Replace the FPM-based RPM package building tooling with our own tooling arcade#15143

• Move SDK to new RPM tooling

• Move aspnetcore to new RPM tooling

• Move dotnet/runtime to new RPM tooling runtime#109518

[jkoritzinsky]

All repos have been moved to the new tooling, so we don't depend on separate docker images any more