Skip to content

Add dotnet to official Linux repositories so it is a credible option for general development #3286

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

Closed
nzbart opened this issue Aug 31, 2019 · 7 comments

Comments

@nzbart
Copy link

nzbart commented Aug 31, 2019

In my day job, I am a .NET developer on Windows, and I use .NET Core for new apps where possible. I am also a heavy Linux user, and - as Microsoft obviously acknowledges - this is where server-side workloads are heading. However, while .NET Core functions on Linux, it is clunky and there is a lot of friction when compared to other languages and platforms that integrate seamlessly.

One example is that support for Debian 10 and Debian Testing across the Microsoft open source products is almost non-existent. Also, the workarounds are problematic because different products support different versions of Debian via the same package repositories. The only viable way to work with .NET Core on any relatively recent release of Debian is to run in a Docker container, which is clunky for day-to-day development. The Snap packages are workable, however, not everything is officially supported on Snap - such as the Azure CLI.

The reality is, that it's simply easier to learn one of the plethora of well supported languages instead, such as Python, Go, or Rust.

Unfortunately, I've been unable to find any official word on why Microsoft doesn't add .NET Core and other tools to the official Debian (and therefore Ubuntu) repositories, so I'm left to speculate. I've come up with two possible reasons:

  • The official repositories - and therefore the integrity of the code - are outside of the control of Microsoft. Right now, if I install .NET Core on a Docker container, I can be assured through modern cryptography that I'm installing the packages built on your build servers.

  • The official Debian repositories can be out of date. By providing an orthogonal deployment mechanism, it's possible to deploy the latest version of .NET Core on an older, stable version of Debian.

I'm interested to hear whether there are other reasons, and whether adding .NET Core to the official repositories is completely off the table, or whether it's simply a matter of resourcing and/or overcoming obstacles.

@svick
Copy link
Contributor

svick commented Aug 31, 2019

Unfortunately, I've been unable to find any official word on why Microsoft doesn't add .NET Core and other tools to the official Debian (and therefore Ubuntu) repositories, so I'm left to speculate.

I believe the main reason was actually that .Net Core couldn't satisfy the requirements of distributions when it comes to its build process. The dotnet/source-build repo exists specifically to fix that. I'm not sure what is the status of that work, but based on this page, I think it's still ongoing.

@glaulher
Copy link

they created the package and named it ubuntu 19.04, version with reduced support, but did not put it for the Debian lts buster ... ubunto 19.04 is pretty much Debian buster in package versions.

about dotnet core 2.2:
the Ubuntu 19.04 package works perfectly on debian 10, the systems have the same dependencies.
package creators seem to be unaware of such compatibility, in Debian buster unfortunately have to use the package named ubuntu 19.04 which is fully compatible or use the binaries ..
missing of respect for the Debian user.

@nzbart
Copy link
Author

nzbart commented Aug 31, 2019

@glaulher Packaging for Debian and allowing it to flow down to (the admittedly more popular) Ubuntu, Mint, Kali, and other distributions, seems sensible to me. It's also recommended by Ubuntu:

There are a number of paths that a package can take to enter Ubuntu. In most cases, going through Debian first can be the best path. This way ensures that your package will reach the largest number of users as it will be available in not just Debian and Ubuntu but all of their derivatives as well.

Source: http://packaging.ubuntu.com/html/packaging-new-software.html

@dagood
Copy link
Member

dagood commented Sep 3, 2019

the Ubuntu 19.04 package works perfectly on debian 10, the systems have the same dependencies.
package creators seem to be unaware of such compatibility, in Debian buster unfortunately have to use the package named ubuntu 19.04 which is fully compatible or use the binaries ..

We're aware, the dependencies being the same is intentional. The same Debian package files are actually used across all the distros. There's a discussion at #2576 about making the dropdown track the list of active distros better. There's actually a Debian 10 feed that should work--it just isn't exposed in the dropdown due to some complications.

This is a tangent, though--the Debian packages on dot.net do not meet the Debian distro requirements. @svick is spot on with #3286 (comment).

There are a number of paths that a package can take to enter Ubuntu. In most cases, going through Debian first can be the best path. This way ensures that your package will reach the largest number of users as it will be available in not just Debian and Ubuntu but all of their derivatives as well.

@dseefeld is there a recent doc about what repos we're targeting? dotnet/source-build#782 mentions a few possibilities (including Debian) but I'm not sure if that's up to date.

@dseefeld
Copy link

dseefeld commented Sep 3, 2019

Source-build is targeting Fedora first. Others to follow, but which distro is still up in the air.

@nzbart
Copy link
Author

nzbart commented Sep 4, 2019

Thanks, @dagood. The issue you referenced clearly documents the negative impacts of the current situation. Hopefully Microsoft will prioritise the issue, possibly after .NET Core 3.0 has been released - which I suspect is your current focus.

Making it easy for people to get to "Hello, world" in as few steps as possible is crucial for adoption.

@leecow
Copy link
Member

leecow commented Sep 5, 2019

Thanks for the interest in this project; rest assured that the work is prioritized and we should start to see fruit in the near future. I'm going to close this issue as there are other places where the work is tracked.

@leecow leecow closed this as completed Sep 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants