debian auto-updating package?

[Petermarcu]

@Spongman commented on Fri Dec 08 2017

currently the debian packages are version-specific.

for example, the current package is dotnet-sdk-2.0.2. this package will not upgrade automatically when a new version comes out.

can we get a set of virtual packages doetnet-sdk , dotnet-sdk-x, and dotnet-sdk-x.y that automatically update? (and similar for the runtimes?)

for example, there's only one openjdk-8-jdk package. it installs the latest SDK, and it updates automatically. all packages that follow SemVer correctly can behave in this way without breaking existing clients.

EDIT: oh look at that, the docs i was looking at (https://www.microsoft.com/net/learn/get-started/linuxdebian) are out of date. the latest package is actually dotnet-sdk-2.0.3. i think this illustrates perfectly the need for non-version-specific packages.

---

@richlander commented on Sat Dec 09 2017

PTAL @leecow

[leecow]

@wli3 @rakeshsinghranchi - This covers one of the bigger issues we need to work out with all of our native installer on Linux. I'll book some time to talk things through.

[wli3]

Agree, it is a hard problem. We don't know which point the user want to upgrade instead of running it side by side. Also, we would need more test coverage on different SDK * runtime version.

[Spongman]

As long as you're following SemVer correctly (specifically: point releases are backwardly compatible) then SxS should not be necessary.

[wli3]

I think we need to solve the problem below to enable it with confident.

For Windows and Mac installer. When you install a specific version of SDK, you will get a specific version of runtime, in most of the case, the latest. However, if we allow SDK(say 2.1.X) to depend on a range of runtime, say >= 2.0.0. When the user install the latest SDK, if there is a compatible runtime existed. Runtime won't get updated. This is a good behavior for user, however, I don't think we have enough test coverage for new SDK to run on old runtime (also multiply with asp.net runtime).

Also, I believe this will require runtime and SDK version to be 100% semver @KathleenDollard , or we need another place to track which SDK can run on which runtime. And which version range of SDK my Debian package can depend on.

Also, the dependency range(written by msbuild) should be in sync with runtime policy, which is C++ code.

The version selection is a behavior of apt-get/yum and its feed, to fully test it, we also need end to end infrastructure to avoid things like prerelease has high priority over release. But during development, due to prerelease runtime won't move forward, we usually test a specific version with a specific runtime. It is hard for us to discover bugs that comes from different versions compatibility and the version selection itself (say a typo of >= 2.0 vs >=2.0.0), until the actual release.

[Spongman]

However, if we allow SDK(say 2.1.X) to depend on a range of runtime, say >= 2.0.0

why wouldn't you just specify the minimum runtime version that the SDK requires? and have the package manager automatically update to that if necessary? this is precisely the problem that dpkg/apt is designed to solve.

[Petermarcu]

@wli3 , sounds like we need to ensure there is SDK test coverage for running on the latest as well as min version for each train as part of this.

[omajid]

See dotnet/docs#4538 for the updated package design that should make this much better. It incorporates the design of (auto-updating) RHEL/Fedora (copr) packages.

[github-actions]

Due to lack of recent activity, this issue has been labeled as 'stale'. It will be closed if no further activity occurs within 30 more days. Any new comment will remove the label.

[github-actions]

This issue will now be closed since it has been labeled 'stale' without activity for 30 days.