Include native dependencies for RPM and DEB #71

Open
opened 2026-01-29 16:28:33 +00:00 by claunia · 2 comments
Owner

Originally created by @clemensv on GitHub (Dec 8, 2019).

Originally assigned to: @clemensv on GitHub.

It would be great if the target rules for the build would include the per-runtime native dependencies for inclusion in the RPM and DEB files. @davidfowl agrees that figuring out the dependencies is far too hard, but until dotnet core includes a list of dependencies in its target files, it would be great if this tool would do it.

I’ll be happy to put that together if you assign the bug to me.

Originally created by @clemensv on GitHub (Dec 8, 2019). Originally assigned to: @clemensv on GitHub. It would be great if the target rules for the build would include the per-runtime native dependencies for inclusion in the RPM and DEB files. @davidfowl agrees that figuring out the dependencies is far too hard, but until dotnet core includes a list of dependencies in its target files, it would be great if this tool would do it. I’ll be happy to put that together if you assign the bug to me.
Author
Owner

@qmfrederik commented on GitHub (Dec 9, 2019):

@clemensv There's a default list of dependencies for RPM here:

35c55a82c8/Packaging.Targets/build/Packaging.Targets.targets (L46-L82)

and for DEB files here:

35c55a82c8/Packaging.Targets/build/Packaging.Targets.targets (L132-L153)

with the idea being that:

  • If you have a framework-dependent app, you'll end up with a dependency on the framework
  • If you have a self-contained app, you'll end up with a dependency on the framework dependencies

There's a couple of flaws in the logic that I know of:

  • This doesn't account for apps that depend on ASP.NET Core
  • You'll end up with a dependency on dotnet-runtime-.x.y on ARM64, but Microsoft doesn't provide ARM64 packages for the .NET runtime

So yeah, happy to take any PRs that improve this scenario :)

@qmfrederik commented on GitHub (Dec 9, 2019): @clemensv There's a default list of dependencies for RPM here: https://github.com/qmfrederik/dotnet-packaging/blob/35c55a82c8594b341cecdd075328f7e60091c112/Packaging.Targets/build/Packaging.Targets.targets#L46-L82 and for DEB files here: https://github.com/qmfrederik/dotnet-packaging/blob/35c55a82c8594b341cecdd075328f7e60091c112/Packaging.Targets/build/Packaging.Targets.targets#L132-L153 with the idea being that: - If you have a framework-dependent app, you'll end up with a dependency on the framework - If you have a self-contained app, you'll end up with a dependency on the framework dependencies There's a couple of flaws in the logic that I know of: - This doesn't account for apps that depend on ASP.NET Core - You'll end up with a dependency on `dotnet-runtime-.x.y` on ARM64, but Microsoft doesn't provide ARM64 packages for the .NET runtime So yeah, happy to take any PRs that improve this scenario :)
Author
Owner

@xsacha commented on GitHub (Feb 26, 2020):

Is there a way to have a variable version number in there because obviously this doesn't work for dotnet-runtime-3.1 now (or any future version).

@xsacha commented on GitHub (Feb 26, 2020): Is there a way to have a variable version number in there because obviously this doesn't work for dotnet-runtime-3.1 now (or any future version).
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dotnet-packaging#71