Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

You need to take back charge of your Linux packaging #44901

Closed
the-black-wolf opened this issue Nov 16, 2024 · 15 comments
Closed

You need to take back charge of your Linux packaging #44901

the-black-wolf opened this issue Nov 16, 2024 · 15 comments
Assignees
Labels
Area-Linux untriaged Request triage from a team member

Comments

@the-black-wolf
Copy link

You guys messed up Ubuntu release by giving it to Canonical. In their infinite wisdom they think dotnet is just the latest version of solitaire and will neither support older versions of itself nor older versions of dotnet. Making it practically useless except for runtime of the latest code. And apparently that is enough for dotnet crew here to say "oh, fine, now Canincal has this covered".

No, they do not. At best they will use this to contineu to try and shove snap down our throats.

You do realize that just because you no longer support something, that is DOES NOT mean there is no running code in the wild for that? Especially in enterprise where upgrading old code base on a 3 year cycles is a dubious requirement at best. I am not talking about an ideal situation here, I am talking about reality (the same reality that causes a lot of enteprises to stick with Java8)

It is ludicrous that at this day and age we have to do manual installs of dotnet sdk to be able to use it. You need to take back the charge of your own repository and provide packaging. For ALL released versions of dotnet. Exactly the same as I am able to do by installing Visual Studio on Windows. The same as I can install older SDK on Windows. Canonical cannot be trusted to do that for you.

Copy link

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 dotnet-issue-labeler bot added the untriaged Request triage from a team member label Nov 16, 2024
Copy link

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.

@richlander
Copy link
Member

.NET 6+ is available in 24.04 and almost the same in 22.04. This was previously announced at: https://devblogs.microsoft.com/dotnet/whats-new-for-dotnet-in-ubuntu-2404/.

$ cat /etc/os-release | head -n 1
PRETTY_NAME="Ubuntu 24.04.1 LTS"
$ sudo add-apt-repository ppa:dotnet/backports
PPA publishes dbgsym, you may need to include 'main/debug' component
Repository: 'Types: deb
URIs: https://ppa.launchpadcontent.net/dotnet/backports/ubuntu/
Suites: noble
Components: main
'
Description:
The backports archive provides source-built .NET packages in cases where a version of .NET is not available in the archive for an Ubuntu release.

Currently available Ubuntu releases and .NET backports:

Ubuntu 24.04 LTS (Noble Numbat)
├── .NET 6.0 (End of Life on November 12th, 2024) [amd64 arm64]
├── .NET 7.0 (End of Life on May 14th, 2024)      [amd64 arm64]
└── .NET 9.0 (End of Life on May 11th, 2026)      [amd64 arm64 s390x ppc64el]

Ubuntu 22.04 LTS (Jammy Jellyfish)
└── .NET 9.0 (End of Life on May 11th, 2026)      [amd64 arm64 s390x ppc64el]

This seems to be a pretty broad offering. Perhaps you were operating on different assumptions.

@pinkfloydx33
Copy link

On 22.04 it seems that the Canonical feeds only allow installing one version at a time, which was not how it was before. We're having issues getting our build agents to include 6,8 and 9 but everything goes haywire once we include the backports feed.

  • Microsoft feed: 6/8 install side-by-side; installing 9 from the backports then uninstalls 6/8
  • Canonical: each successive install removes any previous; we can have one of 6/8/9

Oddly enough I somehow installed dotnet-sdk-9.0 a week ago from the Microsoft feed side-by-side with 6/8 on 22.04. But that no longer seems to work (no package to install).

@richlander
Copy link
Member

Can you show me the steps? I just validated the experience on Ubuntu 22.04. Works for me.

I don't know how you would have ended up with dotnet-sdk-9.0 unless you registered the Debian 12 feed?

rich@mazama:~$ docker run --rm -it ubuntu:jammy
root@1b02995b4076:/# cat /etc/os-release | head -n 1
PRETTY_NAME="Ubuntu 22.04.5 LTS
root@1b02995b4076:/# apt update
root@1b02995b4076:/# apt install software-properties-common
root@1b02995b4076:/# add-apt-repository ppa:dotnet/backports
# add-apt-repository ppa:dotnet/backports
PPA publishes dbgsym, you may need to include 'main/debug' component
Repository: 'deb https://ppa.launchpadcontent.net/dotnet/backports/ubuntu/ jammy main'
Description:
The backports archive provides source-built .NET packages in cases where a version of .NET is not available in the archive for an Ubuntu release.

Currently available Ubuntu releases and .NET backports:

Ubuntu 24.04 LTS (Noble Numbat)
├── .NET 6.0 (End of Life on November 12th, 2024) [amd64 arm64]
├── .NET 7.0 (End of Life on May 14th, 2024)      [amd64 arm64]
└── .NET 9.0 (End of Life on May 11th, 2026)      [amd64 arm64 s390x ppc64el]

Ubuntu 22.04 LTS (Jammy Jellyfish)
└── .NET 9.0 (End of Life on May 11th, 2026)      [amd64 arm64 s390x ppc64el]
root@1b02995b4076:/# apt install -y dotnet-sdk-6.0 dotnet-sdk-8.0 dotnet-sdk-9.0
root@1b02995b4076:/# dotnet --version
9.0.100
root@1b02995b4076:/# dotnet --info
.NET SDK:
 Version:           9.0.100
 Commit:            a2bc464e40
 Workload version:  9.0.100-manifests.6bf02610
 MSBuild version:   17.12.7+a2bc464e4

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  22.04
 OS Platform: Linux
 RID:         ubuntu.22.04-x64
 Base Path:   /usr/lib/dotnet/sdk/9.0.100/

.NET workloads installed:
There are no installed workloads to display.
Configured to use loose manifests when installing new manifests.

Host:
  Version:      9.0.0
  Architecture: x64
  Commit:       a2bc464e40

.NET SDKs installed:
  6.0.135 [/usr/lib/dotnet/sdk]
  8.0.110 [/usr/lib/dotnet/sdk]
  9.0.100 [/usr/lib/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.35 [/usr/lib/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.10 [/usr/lib/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.0 [/usr/lib/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.35 [/usr/lib/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.10 [/usr/lib/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.0 [/usr/lib/dotnet/shared/Microsoft.NETCore.App]

@richlander
Copy link
Member

I'm pretty happy with this experience. The folks at Canonical offer .NET LTS in their main archive and EOL/STS in their PPA. I have a conversation going with them about previews. Exposing previews in the PPA and/or snaps would be really excellent.

@the-black-wolf
Copy link
Author

@richlander this is not good. This installs dotnet 8.110. latest dotnet8 is 8.404 and it was available in your own repository. I have them on my dev rig right now and yet if I upgrade my OS I will lose them?!?

mmix@blackwolf:~$ dotnet --list-sdks
6.0.428 [/usr/share/dotnet/sdk]
7.0.410 [/usr/share/dotnet/sdk]
8.0.404 [/usr/share/dotnet/sdk]

I dont understand why it's such a big problem for MS to package its repo? Canonical obviously does not know what to do with it, nor does it care, its up to you to make sure we can maintain legacy software, otherwise dotnet is useless except for single project/product companies on CI/CD. That is not a reality for most of enterprises. Nobody is asking for fixes on unsupported dotnets but just point blank removing them or removing already released editons is a weird flex.

@richlander
Copy link
Member

You are making a lot of assumptions that are false. I'll only continue this conversation if you tone it down.

@pinkfloydx33
Copy link

@richlander
We are using a modified fork of the runner-images repo packer builds to build our own self hosted agents images. It uses the Microsoft feed pinned for the dotnet setup. I naively added dotnet-sdk-9.0 to the list of packages to install from apt (with no other changes) and it built successfully and installed 6 8 and 9. I can see in the logs of the build that it successfully pulled them from apt and all three SDKS were installed. This was 11/13.

I reran that same packer build today and 9 couldn't be found and the run failed. That's when I read about how it shouldn't have even been available in the first place and that I need to use the backports repo for 22.04.

I tried removing the Microsoft repo and using the built in canonical feed and that fails to install 9 expectedly. So I added the backports repo. It successfully installs 6 8 and 9 but uninstalls each previous one so I only end up with 9. I've decided I'm going to wait and see how runner-images ends up solving it and just syncing their changes down.

@richlander
Copy link
Member

Thanks for that insight. I have no idea how .NET 9 got pulled in, but I believe you.

@richlander
Copy link
Member

I'm closing this issue. I need a tracking issue that we can turn into the basis of a significant project. I'm not going to do that w/the language, tone, and false assumptions that are used throughout this issue. Clearly, that's not from all parties.

Tracking issue: #45029

@pinkfloydx33
Copy link

Sorry. I probably didn't pick the best issue to respond to in the first place. 😢

Your first reply gave me an idea though and I was able to do a little debugging that might provide some insight (at least for my specific case anyways). Before I go making things worse... Do you want me to add it to your new issue, open a new one or just hang tight?

Again, sorry for the noise.

@richlander
Copy link
Member

None of that was directed at you @pinkfloydx33. Let's continue to move forward on the other issue.

@the-black-wolf
Copy link
Author

@richlander, lol, ok, so ghosting it is. Its not the first time by MS, so its not really surprising, it happened before with -linux RTM monikers (because apparently having a dbus related libraries are just as useful on windows) and WPF even refusing 3rd party Linux ports. Ridiculous excuses and refusal of any criticism, closing discussions when not to your liking, citing "tone" whenever you don't like what is discussed. Its a first one though where you guys apologized to a completely random guy who added his vaguely related comment on my issue and then using the fake outrage to close it. Love it. Stuff of legends.

But don't worry, as I said we are used to this from MS and having their "love of Linux" be controlled by Windows. We discussed this and we'll just repackage the 8/404 tarball, so feel free to keep the issue closed (not that I can reopen it, must be nice having that much power to silence people). On a related note, Canonical used to have dotnet before and they messed it up and failed to keep step, they'll probably do it again because its not really their forte and not really something they would prioritize. I still think you should have a unified build system for all supported platforms and keep control of your delivery on all supported OS/distros. But thats just me, what do I know.

TL;DR: I still cant get 8.0.404, which I used to have, but its important the tone of my voice is not per liking.

@the-black-wolf
Copy link
Author

@richlander, just in case you are interested, not sure, kindly dont get offended, just so that its not left unsaid. I installed 22.04 (still LTS), purged all dotnet aspnet and netstandard, added backport ppa (like you did and never gave me a chance to try), added MS prod repo (because i need it for mssql) but deprioritized dotnet/aspnet/netstand from prod repo. I then installed dotnet6, 7, 8 and 9. This is what was installed:

x@y:/etc/apt/preferences.d# dotnet --list-sdks
6.0.135 [/usr/lib/dotnet/sdk]
7.0.119 [/usr/lib/dotnet/sdk]
8.0.110 [/usr/lib/dotnet/sdk]
9.0.100 [/usr/lib/dotnet/sdk]
x@y:/etc/apt/preferences.d# dotnet --list-runtimes
Microsoft.AspNetCore.App 6.0.35 [/usr/lib/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.19 [/usr/lib/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.10 [/usr/lib/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.0 [/usr/lib/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.35 [/usr/lib/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.19 [/usr/lib/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.10 [/usr/lib/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.0 [/usr/lib/dotnet/shared/Microsoft.NETCore.App]

Even if we ignore that all SDKs are on .1xx (which is still in bad taste) and just focus on runtime, only dotnet9 is on the latest released runtime (being new and only). All the other are not at the latest version released (8.0.11, 7.0.20 and 6.0.36). Its been 10 days since the release, and they have been released at the same time as 9, and you support them, and its still not in Canonical repo and we have to use tarot to figure out when it will be. So much about Canonical being in the loop on fixes. This has been a problem with them before, hence my issue. It will happen again, best case scenario I would see latest dotnet fixes on ESM if they think they could get some cash out of it, or some folk with make wild and untrustable ppas. They want to do everything, but then they lose focus and deprioritize this due to their limited resources and focus on other Linux/Ubuntu things, which is fine, really, this is just one small component in their repo. While at the same time you test your code during your builds (and you provide latest tarballs) and are in a position to publish everything timely. Yet, you can't wait to be rid of that responsibility for Linux by passing it on to a crew that has far lower interest in it making us all wait on them and wondering when and how they will remove legacy things from their repos. Does Apple package your dotnet for MacOS?

Do with this info what you want, I am out.

@dotnet dotnet locked as too heated and limited conversation to collaborators Nov 22, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Area-Linux untriaged Request triage from a team member
Projects
None yet
Development

No branches or pull requests

5 participants