Core: Not all latest 2.2.* SDKs are available on Microsoft Debian package feeds

[dagood]

For example, for Ubuntu 19.04, only one version is available (as of writing):

https://packages.microsoft.com/ubuntu/19.04/prod/pool/main/d/dotnet-sdk-2.2/

• dotnet-sdk-2.2.204-x64.deb

For 18.04, there are more, but it's incomplete vs. the table at https://dotnet.microsoft.com/download/dotnet-core/2.2.

https://packages.microsoft.com/ubuntu/18.04/prod/pool/main/d/dotnet-sdk-2.2/

• dotnet-sdk-2.2.100-x64.deb
• dotnet-sdk-2.2.101-x64.deb
• dotnet-sdk-2.2.102-x64.deb
• dotnet-sdk-2.2.103-x64.deb
• dotnet-sdk-2.2.104-x64.deb
• dotnet-sdk-2.2.105-x64.deb
• dotnet-sdk-2.2.202-x64.deb
• dotnet-sdk-2.2.203-x64.deb
• dotnet-sdk-2.2.204-x64.deb
• dotnet-sdk-2.2.300-x64.deb

I think it's normal that 19.04 doesn't have the outdated/insecure versions, but it seems reasonable to expect the latest from each 2.2.1XX, 2.2.2XX, 2.2.3XX train.

A specific case where this is desired is being able to use the same SDK version across VS, VS for Mac, and Linux. More info at https://github.com/dotnet/core-setup/issues/679.

---

What causes these to be available or not?

Can coverage be improved so people can target a single SDK version across platforms without resorting to tar.gz installs?

@leecow

[mmisztal1980]

dotnet-sdk-2.2.107 is the highest available SDK version for MacOS,
if I introduce global.json which constrains usage to this version of the SDK, I can have 2 developers work on the solution using Windows & MacOS, however I can't have an Ubuntu build agent for it - which seems awkward

[leecow]

Including only the latest major.minor SDK in the Linux feed is deliberate. Because the SDKs are fully backward compatible with respect to targeting and building applications, can folks help me understand the benefit of having something like 2.2.1xx, 2.2.2xx and 2.2.3xx all available? Keep in mind that only the latest would be offered via apt-get update dotnet-sdk-2.2. To install a "downgrade" version, you would need to do something like apt-get install dotnet-sdk-2.2=2.2.204-1.

[dagood]

https://github.com/dotnet/core-setup/issues/679 contains some discussion about global.json limitations causing this to be required, I'm not sure I have the full picture though.

[wfurt]

as far as 19.04, and 18.04 - or may not be out stable at time when older sdks were built, right? Also 18.04 comes with openssl-1.1 and support for that was fixed and backported after initial 2.x went out.

[dagood]

as far as 19.04, and 18.04 - or may not be out stable at time when older sdks were built, right?

This is true, but the request isn't for older SDKs, rather the latest version in each feature band. (Feature band is the hundreds place in the SDK minor version. 2.2.300, 2.2.203, and 2.2.107 are the latest in each of those feature bands, and they were all released on 2019-05-14.)

Also 18.04 comes with openssl-1.1 and support for that was fixed and backported after initial 2.x went out.

I'm not sure what this means in this context, can you clarify?

[wfurt]

I'm not sure about 2.2 but back then new distributions had opensssl we could not work with. That was fixed in master and back-ported to 2.x branches.

[dagood]

It sounds like you're saying we can't run older runtimes on new distros, which is true, but SDK 2.2.300/2.2.203/2.2.107 all ship with Runtime 2.2.5, so I'm not sure how it's related.

[carlossanlop]

@dagood @leecow was this resolved? Should we close this or do we need additional followup?

[mthalman]

Including only the latest major.minor SDK in the Linux feed is deliberate. Because the SDKs are fully backward compatible with respect to targeting and building applications, can folks help me understand the benefit of having something like 2.2.1xx, 2.2.2xx and 2.2.3xx all available?

@leecow - One scenario where this can be useful is for pinning. In order to control dependencies, automated scripts will often specify the exact version of packages to be installed so that the script is repeatable (you get the same result no matter at what point in time you run the script). This is particularly relevant to Dockerfiles where caching is involved. Docker builds use caching such that a given layer (consisting of one or more shell commands) will be skipped if it's already been run before. This can be problematic if the same command yields different results, such as installing a package by its major/minor version that has been serviced. To solve this, authors will often using pinning to specify the full version. That way, they explicitly change the version which will cause the cache to be invalidated and the command to be re-run on the next build.

[leecow]

Looks like things are fairly complete (didn't do an exhaustive search). Let me know if there are specific SDK versions missing for a given repo and I'll get it updated.

[leecow]

I think this is resolved.