[Bug 2134482] [NEW] [MIR] dotnet10
Dominik Viererbe
2134482 at bugs.launchpad.net
Tue Dec 9 14:46:39 UTC 2025
Public bug reported:
As disussed the previous MIR's for dotnet6 (LP: #2023531) and dotnet8 (LP: #2060056)
we would like to include the dotnet10 package in Ubuntu main for resolute and noble as
part of our toolchain strategy.
Note: dotnet10 is not yet available on noble.
[Availability]
The package dotnet10 is already in Ubuntu universe.
The package dotnet10 build for the architectures it is designed to work on.
It currently builds and works for architectures: amd64, arm64, ppc64el, s390x
Link to package https://launchpad.net/ubuntu/+source/dotnet10
[Rationale]
- The package dotnet10 is required in Ubuntu main as part of
Canonicals partnership with Microsoft to shorten the supply
chain between Canonical and Microsoft and improve the .NET
developer experience on Ubuntu. Read more here:
- https://canonical.com/blog/install-dotnet-on-ubuntu
- https://devblogs.microsoft.com/dotnet/announcing-dotnet-security-group/
- https://devblogs.microsoft.com/dotnet/dotnet-6-is-now-in-ubuntu-2204/
- The package dotnet10 will generally be useful for a large part of
our user base.
- The package dotnet10 has no reverse-dependencies.
- This is the first time the binary packages built by dotnet10 will be in main,
but binary packages built by dotnet6 (MIR LP: #2023531) and dotnet8 (MIR LP: #2060056)
(previous LTS versions of .NET) are in main.
- All binary packages built by dotnet10 need to be in main, except for the
debug symbol packages (end with "-dbg-10.0") and dotnet-sdk-10.0-source-built-artifacts.
To be explicit:
- The following binary packages built by dotnet10 need to be in main:
- aspnetcore-runtime-10.0: ASP.NET Core runtime
- aspnetcore-targeting-pack-10.0: Internal - targeting pack for Microsoft.AspNetCore.App 10.0
- dotnet-apphost-pack-10.0: Internal - targeting pack for Microsoft.NETCore.App 10.0
- dotnet-host-10.0: .NET host command line
- dotnet-hostfxr-10.0: .NET host resolver
- dotnet-runtime-10.0: .NET runtime
- dotnet-sdk-10.0: .NET 10.0 Software Development Kit
- dotnet-sdk-aot-10.0: .NET platform NativeAOT components.
- dotnet-targeting-pack-10.0: Internal - targeting pack for Microsoft.NETCore.App 10.0
- dotnet-templates-10.0: .NET 10.0 templates
- dotnet10: .NET CLI tools and runtime
- The following binary packages built by dotnet10 need to stay in universe:
- aspnetcore-runtime-dbg-10.0: ASP.NET Runtime debug symbols.
- dotnet-runtime-dbg-10.0: .NET Runtime debug symbols.
- dotnet-sdk-dbg-10.0: .NET SDK debug symbols.
- dotnet-sdk-10.0-source-built-artifacts: Internal package for building the .NET 10.0 Software Development Kit
- It would be great and useful to community/processes to have the
package dotnet10 in Ubuntu main, but there is no definitive deadline.
[Security]
- No CVEs/security issues in this software yet, because it is a new
major version of .NET and a new package in Ubuntu. Comparable older major
versions of .NET had multiple security issues in the past that have been promtly fixed:
- dotnet6:
- https://ubuntu.com/security/cves?package=dotnet6
- https://github.com/dotnet/core/blob/main/release-notes/6.0/cve.md
- dotnet7:
- https://ubuntu.com/security/cves?package=dotnet7
- https://github.com/dotnet/core/blob/main/release-notes/7.0/cve.md
- dotnet8:
- https://ubuntu.com/security/cves?package=dotnet8
- https://github.com/dotnet/core/blob/main/release-notes/8.0/cve.md
- dotnet9:
- https://ubuntu.com/security/cves?package=dotnet9
- https://github.com/dotnet/core/blob/main/release-notes/9.0/cve.md
- Microsoft releases updates for every supported .NET version every Month (on the
second Tuesday of the Month called "Patch Tuesday"). Canonical is part of the
.NET security group (https://devblogs.microsoft.com/dotnet/announcing-dotnet-security-group/).
As part of the .NET security group Microsoft discloses CVE details to us in advance,
additionally we get access to patches in advance. This allows the Ubuntu Security team
to deliver security updates at the same time when the CVEs are publicly disclosed.
- no `suid` or `sgid` binaries
- no executables in `/sbin` and `/usr/sbin`
- Package does not install services, timers or recurring jobs
- Isolation/risk-mitigation patterns are not in place utilizing the following features:
TBD (add details and links/examples about things like dropping
permissions, using temporary environments, restricted users/groups,
seccomp, systemd isolation features, apparmor, ...)
- Packages does not open privileged ports (ports < 1024).
- Package does not expose any external endpoints
- Packages does not contain extensions to security-sensitive software
(filters, scanners, plugins, UI skins, ...)
- dotnet10 by default does not open privileged ports, expose any external endpoints,
start services, contain extensions to security-sensitive software, etc.
BUT, because it is a toolchain package it is capable to build and run applications
that can do that. Simmilarly, because it is a toolchain package it also
does not contain isolation features, as this would limit its usecases for
software development.
- dotnet10 relies on the system-provided libssl crypto library for all cryptographic
operations, reducing the risk of implementation errors.
[Quality assurance - function/usage]
- The package works well right after install
[Quality assurance - maintenance]
- The package is not available in Debian
- The package is maintained well in Ubuntu/Upstream and does
not have too many, long-term & critical, open bugs
- Ubuntu: https://bugs.launchpad.net/ubuntu/+source/dotnet10/+bug
- There are multiple bug trackers upstream for the individual
components of the package https://github.com/dotnet
- Upstream's bug tracker, e.g., GitHub Issues
- The package does not deal with exotic hardware we cannot support
[Quality assurance - testing]
- The package runs a test suite on build time, if it fails
it makes the build fail.
See: https://git.launchpad.net/ubuntu/+source/dotnet10/tree/debian/rules?id=35b79da95c88862140bed26e267d8f477464157d#n183
- The package runs an autopkgtest, and is currently passing on
- resolute/amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-resolute/resolute/amd64/d/dotnet10/20251204_035808_792b9@/log.gz
- resolute/arm64: https://autopkgtest.ubuntu.com/results/autopkgtest-resolute/resolute/arm64/d/dotnet10/20251204_042750_792b9@/log.gz
- resolute/ppc64el: https://autopkgtest.ubuntu.com/results/autopkgtest-resolute/resolute/ppc64el/d/dotnet10/20251205_081849_792b9@/log.gz
- resolute/s390x: https://autopkgtest.ubuntu.com/results/autopkgtest-resolute/resolute/s390x/d/dotnet10/20251204_175040_9c0e6@/log.gz
- questing/amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-questing/questing/amd64/d/dotnet10/20251201_131732_1ed0a@/log.gz
- questing/arm64: https://autopkgtest.ubuntu.com/results/autopkgtest-questing/questing/arm64/d/dotnet10/20251129_002547_c7a74@/log.gz
- questing/ppc64el: https://autopkgtest.ubuntu.com/results/autopkgtest-questing/questing/ppc64el/d/dotnet10/20251128_222012_a8dbe@/log.gz
- questing/s390x: https://autopkgtest.ubuntu.com/results/autopkgtest-questing/questing/s390x/d/dotnet10/20251128_220528_c81dd@/log.gz
- The package does have not failing autopkgtests right now
[Quality assurance - packaging]
- debian/watch is not present, because the capabilities of watch files are not compatible
with our (Canonical toolchains team) workflow. We gets early access to releases from
Upstream. Additionally we are repacking the original source to remove unneded (e.g.
windows-only) files and embed a manifest file. This process is semi-automatic and
requires minimal human involvement to kick-off.
This is the GitHub workflow we use to build the orig tarball: https://github.com/canonical/dotnet-source-build/blob/main/.github/workflows/build-orig-tarball.yaml
Upstream has a regular release schedule (every 2nd Tuesday of a month) and we are in
weekly converstations with Upstream. They update us about the status of scheduled
releases or notify us about unscheduled releases (which are very rare).
- debian/control defines a correct Maintainer field
- This package does not yield massive lintian Warnings, Errors
- Lintian overrides are present, but ok. The reasons are documented as a comment
in the override files, e.g.: https://git.launchpad.net/ubuntu/+source/dotnet10/tree/debian/source/lintian-overrides?id=35b79da95c88862140bed26e267d8f477464157d
- This package does not rely on obsolete or about to be demoted packages.
- This package has no python2 or GTK2 dependencies
- The package will not be installed by default
- Packaging is complex, but that is ok because that is expected from a toolchain package.
.NET is a complex software package, because it requires bootstrapping for its initial
build, because it depends on itself. Over the last years we were able to reduce the
complexity and further continue this effort together with Microsoft and other
Linux distro maintainers involved in building .NET for Linux.
[UI standards]
- Application is end-user facing, Translation is NOT present,
this is ok, as the application just provides a Command Line
Interface for developers. The CLI output should not be
translated to maintain online searchable error messages.
- The exception messages of the .NET Runtime are localized.
- End-user applications without desktop file, not needed,
because it just provides libraries and command line tools
[Dependencies]
- There are further dependencies that are not yet in main, MIR for them
is is not needed as they are just build depenencies
$ check-mir
Checking support status of build dependencies...
* clang-20 is in universe, but its source llvm-toolchain-20 is already in main; file an ubuntu-archive bug for promoting the current preferred alternative
* dotnet-sdk-10.0 binary and source package is in universe
* dotnet-sdk-10.0-source-built-artifacts binary and source package is in universe
* lld-20 is in universe, but its source llvm-toolchain-20 is already in main; file an ubuntu-archive bug for promoting the current preferred alternative
* llvm-20 is in universe, but its source llvm-toolchain-20 is already in main; file an ubuntu-archive bug for promoting the current preferred alternative
* rapidjson-dev binary and source package is in universe
* tree binary and source package is in universe
Checking support status of binary dependencies...
* dotnet-sdk-10.0 binary and source package is in universe
* dotnet-host-10.0 binary and source package is in universe
* dotnet-hostfxr-10.0 binary and source package is in universe
* dotnet-runtime-10.0 binary and source package is in universe
* dotnet-host-10.0 binary and source package is in universe
* aspnetcore-runtime-10.0 binary and source package is in universe
* aspnetcore-targeting-pack-10.0 binary and source package is in universe
* dotnet-apphost-pack-10.0 binary and source package is in universe
* dotnet-runtime-10.0 binary and source package is in universe
* dotnet-targeting-pack-10.0 binary and source package is in universe
* dotnet-templates-10.0 binary and source package is in universe
* dotnet-sdk-aot-10.0 binary and source package is in universe
* dotnet-sdk-10.0 binary and source package is in universe
* aspnetcore-runtime-10.0 binary and source package is in universe
* dotnet-runtime-10.0 binary and source package is in universe
* dotnet-sdk-10.0 binary and source package is in universe
[Standards compliance]
- This package correctly follows FHS and Debian Policy
[Maintenance/Owner]
- The owning team will be Foundations (Canonical toolchains team) and I have
their acknowledgment for that commitment
- This package has embedded/vendorized JavaScript files, which were built
from TypeScript. Upsteam, Canonical and RedHat tried to solve this issue, over
the last years but the effort involved to maintain a recent node version and package
all the node dependencies is too enormous.
- This package is not rust based
- The package has been built within the last 3 months in the archive
- Build links on launchpad:
- resolute: https://launchpad.net/ubuntu/+source/dotnet10/10.0.100-10.0.0-0ubuntu2/+build/31550301
- questing: https://launchpad.net/ubuntu/+source/dotnet10/10.0.100-10.0.0-0ubuntu1~25.10.1
- This change will not impact other teams, because dotnet* packages have no reverse depenency
[Background information]
- The Package description explains the package well
- Upstream Name is ".NET 10"
- Link to upstream project https://github.com/dotnet/dotnet
see also https://github.com/dotnet/source-build (repo for everyone with an
interest of building .NET from source)
- dotnet10 is needed in Ubuntu main for resolute and noble
- dotnet10 is not yet available on noble (SRU in progress)
- dotnet6 (LP: #2023531) and dotnet8 (LP: #2060056) already in main
- dotnet* packages have no reverse depenencies
** Affects: dotnet10 (Ubuntu)
Importance: Undecided
Status: New
** Affects: dotnet10 (Ubuntu Noble)
Importance: Undecided
Status: New
** Affects: dotnet10 (Ubuntu Resolute)
Importance: Undecided
Status: New
** Also affects: dotnet10 (Ubuntu Noble)
Importance: Undecided
Status: New
** Also affects: dotnet10 (Ubuntu Resolute)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to dotnet10 in Ubuntu.
https://bugs.launchpad.net/bugs/2134482
Title:
[MIR] dotnet10
Status in dotnet10 package in Ubuntu:
New
Status in dotnet10 source package in Noble:
New
Status in dotnet10 source package in Resolute:
New
Bug description:
As disussed the previous MIR's for dotnet6 (LP: #2023531) and dotnet8 (LP: #2060056)
we would like to include the dotnet10 package in Ubuntu main for resolute and noble as
part of our toolchain strategy.
Note: dotnet10 is not yet available on noble.
[Availability]
The package dotnet10 is already in Ubuntu universe.
The package dotnet10 build for the architectures it is designed to work on.
It currently builds and works for architectures: amd64, arm64, ppc64el, s390x
Link to package https://launchpad.net/ubuntu/+source/dotnet10
[Rationale]
- The package dotnet10 is required in Ubuntu main as part of
Canonicals partnership with Microsoft to shorten the supply
chain between Canonical and Microsoft and improve the .NET
developer experience on Ubuntu. Read more here:
- https://canonical.com/blog/install-dotnet-on-ubuntu
- https://devblogs.microsoft.com/dotnet/announcing-dotnet-security-group/
- https://devblogs.microsoft.com/dotnet/dotnet-6-is-now-in-ubuntu-2204/
- The package dotnet10 will generally be useful for a large part of
our user base.
- The package dotnet10 has no reverse-dependencies.
- This is the first time the binary packages built by dotnet10 will be in main,
but binary packages built by dotnet6 (MIR LP: #2023531) and dotnet8 (MIR LP: #2060056)
(previous LTS versions of .NET) are in main.
- All binary packages built by dotnet10 need to be in main, except for the
debug symbol packages (end with "-dbg-10.0") and dotnet-sdk-10.0-source-built-artifacts.
To be explicit:
- The following binary packages built by dotnet10 need to be in main:
- aspnetcore-runtime-10.0: ASP.NET Core runtime
- aspnetcore-targeting-pack-10.0: Internal - targeting pack for Microsoft.AspNetCore.App 10.0
- dotnet-apphost-pack-10.0: Internal - targeting pack for Microsoft.NETCore.App 10.0
- dotnet-host-10.0: .NET host command line
- dotnet-hostfxr-10.0: .NET host resolver
- dotnet-runtime-10.0: .NET runtime
- dotnet-sdk-10.0: .NET 10.0 Software Development Kit
- dotnet-sdk-aot-10.0: .NET platform NativeAOT components.
- dotnet-targeting-pack-10.0: Internal - targeting pack for Microsoft.NETCore.App 10.0
- dotnet-templates-10.0: .NET 10.0 templates
- dotnet10: .NET CLI tools and runtime
- The following binary packages built by dotnet10 need to stay in universe:
- aspnetcore-runtime-dbg-10.0: ASP.NET Runtime debug symbols.
- dotnet-runtime-dbg-10.0: .NET Runtime debug symbols.
- dotnet-sdk-dbg-10.0: .NET SDK debug symbols.
- dotnet-sdk-10.0-source-built-artifacts: Internal package for building the .NET 10.0 Software Development Kit
- It would be great and useful to community/processes to have the
package dotnet10 in Ubuntu main, but there is no definitive deadline.
[Security]
- No CVEs/security issues in this software yet, because it is a new
major version of .NET and a new package in Ubuntu. Comparable older major
versions of .NET had multiple security issues in the past that have been promtly fixed:
- dotnet6:
- https://ubuntu.com/security/cves?package=dotnet6
- https://github.com/dotnet/core/blob/main/release-notes/6.0/cve.md
- dotnet7:
- https://ubuntu.com/security/cves?package=dotnet7
- https://github.com/dotnet/core/blob/main/release-notes/7.0/cve.md
- dotnet8:
- https://ubuntu.com/security/cves?package=dotnet8
- https://github.com/dotnet/core/blob/main/release-notes/8.0/cve.md
- dotnet9:
- https://ubuntu.com/security/cves?package=dotnet9
- https://github.com/dotnet/core/blob/main/release-notes/9.0/cve.md
- Microsoft releases updates for every supported .NET version every Month (on the
second Tuesday of the Month called "Patch Tuesday"). Canonical is part of the
.NET security group (https://devblogs.microsoft.com/dotnet/announcing-dotnet-security-group/).
As part of the .NET security group Microsoft discloses CVE details to us in advance,
additionally we get access to patches in advance. This allows the Ubuntu Security team
to deliver security updates at the same time when the CVEs are publicly disclosed.
- no `suid` or `sgid` binaries
- no executables in `/sbin` and `/usr/sbin`
- Package does not install services, timers or recurring jobs
- Isolation/risk-mitigation patterns are not in place utilizing the following features:
TBD (add details and links/examples about things like dropping
permissions, using temporary environments, restricted users/groups,
seccomp, systemd isolation features, apparmor, ...)
- Packages does not open privileged ports (ports < 1024).
- Package does not expose any external endpoints
- Packages does not contain extensions to security-sensitive software
(filters, scanners, plugins, UI skins, ...)
- dotnet10 by default does not open privileged ports, expose any external endpoints,
start services, contain extensions to security-sensitive software, etc.
BUT, because it is a toolchain package it is capable to build and run applications
that can do that. Simmilarly, because it is a toolchain package it also
does not contain isolation features, as this would limit its usecases for
software development.
- dotnet10 relies on the system-provided libssl crypto library for all cryptographic
operations, reducing the risk of implementation errors.
[Quality assurance - function/usage]
- The package works well right after install
[Quality assurance - maintenance]
- The package is not available in Debian
- The package is maintained well in Ubuntu/Upstream and does
not have too many, long-term & critical, open bugs
- Ubuntu: https://bugs.launchpad.net/ubuntu/+source/dotnet10/+bug
- There are multiple bug trackers upstream for the individual
components of the package https://github.com/dotnet
- Upstream's bug tracker, e.g., GitHub Issues
- The package does not deal with exotic hardware we cannot support
[Quality assurance - testing]
- The package runs a test suite on build time, if it fails
it makes the build fail.
See: https://git.launchpad.net/ubuntu/+source/dotnet10/tree/debian/rules?id=35b79da95c88862140bed26e267d8f477464157d#n183
- The package runs an autopkgtest, and is currently passing on
- resolute/amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-resolute/resolute/amd64/d/dotnet10/20251204_035808_792b9@/log.gz
- resolute/arm64: https://autopkgtest.ubuntu.com/results/autopkgtest-resolute/resolute/arm64/d/dotnet10/20251204_042750_792b9@/log.gz
- resolute/ppc64el: https://autopkgtest.ubuntu.com/results/autopkgtest-resolute/resolute/ppc64el/d/dotnet10/20251205_081849_792b9@/log.gz
- resolute/s390x: https://autopkgtest.ubuntu.com/results/autopkgtest-resolute/resolute/s390x/d/dotnet10/20251204_175040_9c0e6@/log.gz
- questing/amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-questing/questing/amd64/d/dotnet10/20251201_131732_1ed0a@/log.gz
- questing/arm64: https://autopkgtest.ubuntu.com/results/autopkgtest-questing/questing/arm64/d/dotnet10/20251129_002547_c7a74@/log.gz
- questing/ppc64el: https://autopkgtest.ubuntu.com/results/autopkgtest-questing/questing/ppc64el/d/dotnet10/20251128_222012_a8dbe@/log.gz
- questing/s390x: https://autopkgtest.ubuntu.com/results/autopkgtest-questing/questing/s390x/d/dotnet10/20251128_220528_c81dd@/log.gz
- The package does have not failing autopkgtests right now
[Quality assurance - packaging]
- debian/watch is not present, because the capabilities of watch files are not compatible
with our (Canonical toolchains team) workflow. We gets early access to releases from
Upstream. Additionally we are repacking the original source to remove unneded (e.g.
windows-only) files and embed a manifest file. This process is semi-automatic and
requires minimal human involvement to kick-off.
This is the GitHub workflow we use to build the orig tarball: https://github.com/canonical/dotnet-source-build/blob/main/.github/workflows/build-orig-tarball.yaml
Upstream has a regular release schedule (every 2nd Tuesday of a month) and we are in
weekly converstations with Upstream. They update us about the status of scheduled
releases or notify us about unscheduled releases (which are very rare).
- debian/control defines a correct Maintainer field
- This package does not yield massive lintian Warnings, Errors
- Lintian overrides are present, but ok. The reasons are documented as a comment
in the override files, e.g.: https://git.launchpad.net/ubuntu/+source/dotnet10/tree/debian/source/lintian-overrides?id=35b79da95c88862140bed26e267d8f477464157d
- This package does not rely on obsolete or about to be demoted packages.
- This package has no python2 or GTK2 dependencies
- The package will not be installed by default
- Packaging is complex, but that is ok because that is expected from a toolchain package.
.NET is a complex software package, because it requires bootstrapping for its initial
build, because it depends on itself. Over the last years we were able to reduce the
complexity and further continue this effort together with Microsoft and other
Linux distro maintainers involved in building .NET for Linux.
[UI standards]
- Application is end-user facing, Translation is NOT present,
this is ok, as the application just provides a Command Line
Interface for developers. The CLI output should not be
translated to maintain online searchable error messages.
- The exception messages of the .NET Runtime are localized.
- End-user applications without desktop file, not needed,
because it just provides libraries and command line tools
[Dependencies]
- There are further dependencies that are not yet in main, MIR for them
is is not needed as they are just build depenencies
$ check-mir
Checking support status of build dependencies...
* clang-20 is in universe, but its source llvm-toolchain-20 is already in main; file an ubuntu-archive bug for promoting the current preferred alternative
* dotnet-sdk-10.0 binary and source package is in universe
* dotnet-sdk-10.0-source-built-artifacts binary and source package is in universe
* lld-20 is in universe, but its source llvm-toolchain-20 is already in main; file an ubuntu-archive bug for promoting the current preferred alternative
* llvm-20 is in universe, but its source llvm-toolchain-20 is already in main; file an ubuntu-archive bug for promoting the current preferred alternative
* rapidjson-dev binary and source package is in universe
* tree binary and source package is in universe
Checking support status of binary dependencies...
* dotnet-sdk-10.0 binary and source package is in universe
* dotnet-host-10.0 binary and source package is in universe
* dotnet-hostfxr-10.0 binary and source package is in universe
* dotnet-runtime-10.0 binary and source package is in universe
* dotnet-host-10.0 binary and source package is in universe
* aspnetcore-runtime-10.0 binary and source package is in universe
* aspnetcore-targeting-pack-10.0 binary and source package is in universe
* dotnet-apphost-pack-10.0 binary and source package is in universe
* dotnet-runtime-10.0 binary and source package is in universe
* dotnet-targeting-pack-10.0 binary and source package is in universe
* dotnet-templates-10.0 binary and source package is in universe
* dotnet-sdk-aot-10.0 binary and source package is in universe
* dotnet-sdk-10.0 binary and source package is in universe
* aspnetcore-runtime-10.0 binary and source package is in universe
* dotnet-runtime-10.0 binary and source package is in universe
* dotnet-sdk-10.0 binary and source package is in universe
[Standards compliance]
- This package correctly follows FHS and Debian Policy
[Maintenance/Owner]
- The owning team will be Foundations (Canonical toolchains team) and I have
their acknowledgment for that commitment
- This package has embedded/vendorized JavaScript files, which were built
from TypeScript. Upsteam, Canonical and RedHat tried to solve this issue, over
the last years but the effort involved to maintain a recent node version and package
all the node dependencies is too enormous.
- This package is not rust based
- The package has been built within the last 3 months in the archive
- Build links on launchpad:
- resolute: https://launchpad.net/ubuntu/+source/dotnet10/10.0.100-10.0.0-0ubuntu2/+build/31550301
- questing: https://launchpad.net/ubuntu/+source/dotnet10/10.0.100-10.0.0-0ubuntu1~25.10.1
- This change will not impact other teams, because dotnet* packages have no reverse depenency
[Background information]
- The Package description explains the package well
- Upstream Name is ".NET 10"
- Link to upstream project https://github.com/dotnet/dotnet
see also https://github.com/dotnet/source-build (repo for everyone with an
interest of building .NET from source)
- dotnet10 is needed in Ubuntu main for resolute and noble
- dotnet10 is not yet available on noble (SRU in progress)
- dotnet6 (LP: #2023531) and dotnet8 (LP: #2060056) already in main
- dotnet* packages have no reverse depenencies
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dotnet10/+bug/2134482/+subscriptions
More information about the foundations-bugs
mailing list