© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Response to the review for Source Package: dotnet6
First of all, thanks Christian (~paelzer) & Nishit (~0xnishit) for the extensive review!
Required TODOs:
> #1a
> - Please further clarify the future handling of updates
> Thanks Dviererbe for sharing more details on what happens after EOL.
> Is there a prior example of "providing a transitional package that uninstalls
> all binaries". While I totally understand the motivation it is also
> rather rude.
> People might say "I didn't care for detail X" but now I can't use it
> anymore - or similar.
> Is that approach an established pattern that I missed so far?
> If not we should probably run this by the SRU team (and they decide if also by the TB).
I discussed the EoL Strategy again with Security, Foundations & Microsoft. I documented the outcome in the README.source [1]. TL;DR: We keep the package as is in the archive and demote it to universe. We asked Microsoft to warn the User about EoL. Note that this is also the RedHat EoL strategy for .NET.
You can also find more context about the discussion in the JIRA ticket FR-4855 [2]
> #1b
> - And just to be double sure, you do not intent to e.g. move them
> dotnet6 -> dotnet8, but uninstall it right?
We (Foundations – Toolchains) discussed this approch and rejected it, because this may break some users' use-case or may change the behavior of .NET applications. Especially for users that install multiple runtimes/sdks in parallel.
> #1c
> - Finally, generally and given the impact of the above, is there a draft
> of that "with a clear indication of the MS end of support date in the
> package itself" content? Because with the plan of removal it isn't just
> "the MS end of support" it is "the MS and Ubuntu end of support
> and existence".
As mentioned in the answer for #1a above; this is now documented in the README.source [1].
> #3a
> - You mentioned to need lld and llvm. Please be aware that I've only seen
> build time dependencies to those which since a long time you no more
> strictly need in main. Even then runtime dependencies of things embedding
> llvm features are usually just needing libllvm13/14/15... and those are
> in main already. So do you need to correct your template or have I missed
> how you depend on them?
> #3b
> - If I somehow missed them, even then the MIRs for lld and llvm should not
> be in this bug (it is complex enough) but a new one each and refer to here.
> Just like with the versions here (dotnet6, dotnet7, ...) please ensure you
> keep the list of fully supported releases at a well selected minimum. For
> example rustc pulls llvm-13 into jammy. You use the default which is v14
> on jammy - which would imply two versions in main. I do not even mind on
> which side this is sorted out, but it would help to use the same
> where possible.
This was an error on my side. lld and llvm are not needed. I just thought that they are needed, because the check-mir tool pointed out that they aren't in main.
#4
> - Please point me to the build time tests (More details below in the
> [Common blockers] section.
This was also a confusion on my side. There are no build time tests and I don't know if we want to automatically run the tests during build time, because a build of .NET or running the autopkgtest suite can take hours. There are multiple occasions were a coupled execution of the autopkgtest suite would have slowed down our ability to iterate.
I think this is fine, because we always trigger the autopkgtests in a PPA when a change occurs and the autopkgtests in the proposed pocket have to pass before a new version is deployed to end-users.
Recommended TODOs:
> #2
> - I understand that this oddity of needing .git structures is unavoidable
> right now. But it would be great if you would find a way to patch this
> out in a nice way or at least chime in and adopt upstream issue 3359
> once resolved. I say "a nice way" because if the alternative makes it worse
> there is no benefit.
Robie Basak also suggested this to us, because the need for the .git folder interferes with git-ubuntu. I don't know if we are able to patch this for .NET 6 before EoL, but this is definitely on our TODO for .NET 8.
> #5
> - have a look at filtering d/watch to only one major version (more see in the
> [Packaging red flags] section below)
I "fixed" the watch file. It now can tell correctly if a new upstream version exists, but it will intentionally fail. The reason is also explained in the README.source [3] and there is a comment
in the watch file [4]. TL;DR: The .NET 6 source code is distributed over several public repositories and has no single public place to download the source from. This will change with .NET 8.
> #6
> - while classic symbols tracking isn't very applicable this has way too many
> shared objects that not thinking about it would be ok. More details about
> this request below the [Packaging red flags] section.
> #7
> - In the context of tests (#4) and ABI tests (#6) I've seen mentioning of a
> JIT test (https:/
> https:/
> I've not seen that on build not autopkgtest time.
> They mention running on Ubuntu 18.04 so it should generally work, could
> adding that to autopkgtests could be a great addition? Please have a look
> at that. Only recommended as I'm not having enough experience on this, the
> request might be unfulfillable.
I have to read up on these topics, but I agree that both should be added if they are fulfillable
[Summary of our TODO-List]
1. Integrate (upstream) smoke tests into autopkgtest suite.
2. Investigate embedded third party dependencies that should/can be patched out of dotnet packages.
3. Patch out need for .git folder.
4. Investigate symbols tracking for .so and .dll files.
5. Investigate enabling LTO.
6a. Investigate state of JIT Tests.
6b. Investigate feasibility of integration into autopkgtest suite
Note: These should not block the main inclusion as the TODOs are all non trivial and not strictly required.
[1] https:/
[2] https:/
[3] https:/
[4] https:/