Add Debian trixie image

[richlander]

It's another Debian release year! My assumption is that we'll start shipping Trixie images in Preview 1, in February. We should look at starting testing in January.

I was unable to make Arm32 work per #1286

I adopted a slightly different pattern, which I think is superior:

• One apt-get updated is consumed by all stages.
• Upstream image is mentioned once
• Removed apt-get upgrade -y, which seems wasteful.

[dotnet-issue-labeler]

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

[dotnet-issue-labeler]

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

[richlander]

I forgot that we don't have Trixie images in our mirror.

@lbussell

[mthalman]

I forgot that we don't have Trixie images in our mirror.

@lbussell

Fixed

[mthalman]

Removed apt-get upgrade -y, which seems wasteful.

Running an upgrade was intentional. See #1226 for an explanation.

[lbussell]

@richlander is there a tracking issue for this on https://github.com/dotnet/core side of things yet?

[richlander]

There is not. I was going to ping @rbhanda about that.

[richlander]

Running an upgrade was intentional.

I assumed. Why do we have a different practice for this repo than for dotnet/dotnet-docker? Is it that we have a different tradeoff on size vs security/compliance?

[rbhanda]

There is not. I was going to ping @rbhanda about that.

dotnet/core#9649

[mthalman]

Running an upgrade was intentional.

I assumed. Why do we have a different practice for this repo than for dotnet/dotnet-docker? Is it that we have a different tradeoff on size vs security/compliance?

Exactly. We don't have the same strictness in these images. It's ok if there's some wasted size in them if it makes our lives easier for maintaining them.

[richlander]

@liveans -- I tested the latest libmsquic on Arm64 and it works there. It doesn't work on x64 for some reason.

I see this:

root@ad82881d09ec:/# dpkg -i libmsquic_2.4.7_amd64.deb 
Selecting previously unselected package libmsquic.
(Reading database ... 5854 files and directories currently installed.)
Preparing to unpack libmsquic_2.4.7_amd64.deb ...
Unpacking libmsquic (2.4.7) ...
dpkg: dependency problems prevent configuration of libmsquic:
 libmsquic depends on libxdp1; however:
  Package libxdp1 is not installed.
 libmsquic depends on libnl-route-3-200; however:
  Package libnl-route-3-200 is not installed.

dpkg: error processing package libmsquic (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 libmsquic

[richlander]

Once the libmsquic issues are resolved, I'm going to do some quick size analysis based on the other feedback.

[liveans]

@richlander Can you also install these packages on x64?

libnuma1 libelf1t64 libbpf1 libxdp1 libnl-3-200 libnl-route-3-200

After than that, it should work

[richlander]

Done. I tested on x64 and Arm64 and that worked. I split the images into their own section so that they are easy to remove when we choose to install the libmsquic package.

I also addressed all of the package-manager-related feedback. I am happy to just apply the team standard. If I missed something, do point it out.