search

dotnet / dotnet-buildtools-prereqs-docker

Used to maintain the Docker images hosted at the mcr.microsoft.com/dotnet-buildtools/prereqs image repository
MIT License
58 stars 103 forks source link

Policy for updating `libmsquic` #1171

Closed richlander closed 2 months ago

richlander commented 3 months ago

When should we update our source-build usage? Notice we are already behind. Ideally we keep up, right?

@wfurt @ami-GS @jkoritzinsky

dotnet-issue-labeler[bot] commented 3 months ago

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.

dotnet-issue-labeler[bot] commented 3 months ago

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.

liveans commented 2 months ago

I agree that this is a pain-point for us, we can forget this easily, but I'm not sure if there is any better solution to this for now.

Notice we are already behind. Ideally we keep up, right?

Yes, we should keep up.

richlander commented 2 months ago

I wanted to zoom out on the Alpine Dockerfiles. Why are we building libmsquic? If it's not available in PMC, then where do users get it? I want to validate that we're testing something that users can actually use. Is there an msquic doc for Alpine users?

liveans commented 2 months ago

I wanted to zoom out on the Alpine Dockerfiles. Why are we building libmsquic? If it's not available in PMC, then where do users get it? I want to validate that we're testing something that users can actually use. Is there an msquic doc for Alpine users?

I don't have the full context for this, but AFAIK there were some discussions about working on packaging for Alpine, not sure tho.

/cc @ManickaP @wfurt

wfurt commented 2 months ago

We are not producing Alpine packages for runtime either AFAIK. As far as the updates, in practice, our user base will be on various versions as well e.g. not anyways on latest. In general we update our test images when there is important fix or new feature we try to consume.

richlander commented 2 months ago

Where are the binary drops for msquic? That isn't obvious to me.

ManickaP commented 2 months ago

I'll try to answer all the questions here:

see: https://github.com/dotnet/dotnet-buildtools-prereqs-docker/pull/1156#discussion_r1705458486 @liveans could you make this into an issue? It shouldn't be that hard to query the latest msquic released version from GH and build that instead of fixed version. Disadvantages: the image still needs to rebuild manually to get the newest package; and it'd automatically consume the latest release which might be broken (e.g. what happened lately with 2.4 release). But we can discuss this in that particular issue, not here.

AFAICT https://packages.microsoft.com/ does not have a way to publish packages for Alpine. The users are expected to build msquic themselves, same way we do. Note that we're aware of this and have https://github.com/dotnet/runtime/issues/83789, but this has had rather low priority so we don't have a fixed date when it'll be solved, if ever.

Because there's no official musl binary of libmsquic we could use.

No, no specific alpine docs. What would you expect there? How to build it, we have https://github.com/microsoft/msquic/blob/main/docs/BUILD.md, that's distro agnostic.

The Alpine set up we have here corresponds exactly to what we expect users to do if they want QUIC to light up. So I think we're testing the right thing here.

richlander commented 2 months ago

Thanks. That's helpful.

It shouldn't be that hard to query the latest msquic released version from GH and build that instead of fixed version.

That's a bad practice for containers. You should be able to go back and re-build an old version that either passed or succeeded and replicate that behavior. Naturally, packages don't do that but then you've opted into packages. For everything else, pinning provides the best experience.

Because there's no official musl binary of libmsquic we could use.

My main point is that this significantly increases the burden for users. Building the code is certainly a pain. It would be nice if the upstream project provided binaries. However, it would be good to hear more requests on that form users.

wfurt commented 2 months ago

certainly with user feedback it would be easier to put more pressure on msquic. Some distributions do that independently - like Arch Linux https://aur.archlinux.org/packages/msquic.