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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2134482

Title:
  [MIR] dotnet10

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dotnet10/+bug/2134482/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to