Remove "Debian Package Tool" in favor of fpm

[ViktorHofer]

Source: https://github.com/dotnet/runtime/tree/master/tools-local/dotnet-deb-tool

This tool currently lives in dotnet/runtime even though it's used in at least dotnet/installer as well: https://github.com/dotnet/installer/blob/7684bd57bf7ed43737d2a388b2aa7270d92b97fd/src/redist/targets/GenerateDebs.targets#L4-L7. Looks like package was manually pushed to the "dotnet-core" feed (cc @mmitche?) and blocks removing that feed in favor of the AzDO feeds (ie dotnet5, dotnet-eng, dotnet-tools).

I'm wondering if we should move the tools as-is to Arcade (and potentially convert it to a global tool) or replace it by something newer?

cc @dleeapho @NikolaMilosavljevic @dagood @eerhardt

[ViktorHofer]

cc @dsplaisted for dotnet/installer's usage.

[dagood]

We already use the cross-distro fpm tool to build RPM packages--I think we should use it for Debian packages too, and delete dotnet-deb-tool. This removes the arbitrary limitation to have to build Deb/RPM packages on a matching build image, so the dev experience and official build can be significantly improved.

We have an old issue tracking moving dotnet-deb-tool to Arcade, though: https://github.com/dotnet/runtime/issues/3047.

A background note: since Arcade onboarding (dotnet/core-setup 3.1), dotnet-deb-tool isn't actually consumed as a package by dotnet/core-setup or dotnet/runtime. https://github.com/dotnet/core-setup/commit/58efb317558e34b805ec8e8650a3b3dcede21fcd. (Yes, that puts the dotnet/installer usage in a weird place if we ever needed to service.)

[dagood]

Looks like package was manually pushed to the "dotnet-core" feed (cc @mmitche?) and blocks removing that feed [from dotnet/installer(?)] in favor of the AzDO feeds (ie dotnet5, dotnet-eng, dotnet-tools).

The conclusion I get from this is that dotnet-eng or dotnet-tools is missing the package, not that something's blocked.

[dsplaisted]

FYI @wli3

[wli3]

If we decide to remove "dotnet-deb-tool". I hope someone from central engineering team can contribute the conversion from "dotnet-deb-tool" to "fpm" in dotnet/installer. Or it should be maintained until we have bandwidth to work on this conversion - at least post November

[NikolaMilosavljevic]

This is a good feature - we should use fpm to build deb packages.

[jkoritzinsky]

For the initial version, the new shared framework SDK will directly use the package_tool script that dotnet-deb-tool launches. For future versions, we should be able to move to fpm.

[ViktorHofer]

Now that the Shared Framework SDK got merged into master and proven to be successful, should we continue the discussion to move to fpm and away from dotnet-deb-tool? Who would be driving that effort? cc @NikolaMilosavljevic

[NikolaMilosavljevic]

[Triage] Both runtime and installer should use the new shared tooling.

[safern]

@NikolaMilosavljevic this would unblock: https://github.com/dotnet/runtime/issues/45396 -- do you have an ETA on when this will be ready?

[ViktorHofer]

ping @NikolaMilosavljevic @dleeapho