Update Linux package repository install instructions: reference EOL distro versions

[dagood]

Originally: Update openSUSE Leap install instructions: references EOL 42.2 version

I noticed that Fedora 27 and Fedora 28 share the "27" feed, and 27 is actually EOL too, so that's in a similar situation. This should go all the way up to Fedora 30 now.

---

From https://github.com/dotnet/core-setup/issues/5662#issuecomment-482006340:

https://dotnet.microsoft.com/download/linux-package-manager/opensuse/sdk-2.2.105 still contains openSUSE Leap and then gives instructions relevant to 42.2, which is out of lifetime.
Instead the drop down menu should list openSUSE Leap 42.3 and openSUSE Leap 15.0 like it does Ubuntu 18.10 and Ubuntu 16.04.

Currently the download page looks (in part) like this:

The "42.2" in the URL implies the instructions are out of date for 42.3 and 15.0 (where current distro support is). FWIW, the runtime deps package will work for both once https://github.com/dotnet/core-setup/issues/5628 is implemented.

@rowanmiller @leecow Can you take care of getting these entries updated in general?

[rowanmiller]

Does this just require updating the instructions, or are changes needed to make packages available on the relevant feeds first?

[dagood]

@leecow and @vivmishra are probably able to answer that question.

(Some more context from the core-setup issue: individual 42.3 and 15 (.0?) feeds do already exist (https://packages.microsoft.com/config/opensuse/) but I don't know what's on them so I'm not sure what should be linked to.)

[leecow]

I've been reluctant to chase the repo versioning when installers and dependencies are compatible across distro versions. Looking at this again to develop a plan/process for maintenance.

[rowanmiller]

Any action required on the website now, or should we leave the instructions as-is for the moment?

[dagood]

It sounds like we're waiting on @leecow to figure out the way to handle this.

[karelz]

@leecow @dagood what is the next step here?

[dagood]

Waiting for:

[@leecow] I've been reluctant to chase the repo versioning when installers and dependencies are compatible across distro versions. Looking at this again to develop a plan/process for maintenance.

[carlossanlop]

@leecow any updates on this?

[vivmishra]

I agree with Lee, that chasing repo versioning when installers/dependencies are compatible across distro versions is an overkill.

Maybe we can just make the strings in Linux Distribution drop-down a bit generic, like "Fedora 2X - x64". Something to figure out when Lee is back.

[dagood]

Maybe we can just make the strings in Linux Distribution drop-down a bit generic, like "Fedora 2X - x64". Something to figure out when Lee is back.

This solution doesn't work, because other products' packages may be more or less generic than .NET Core packages, and only one Azure Linux Repo can be configured on a machine at one time. By telling .NET Core users to install a less generic feed than, say, PowerShell, we will break them being able to install/update PowerShell packages. Similarly, a user trying to install PowerShell could break their .NET Core install capabilities. (This has happened.)

IMO we need to coordinate, have a central authority chase down the distros/versions and provide install instructions for each one, so that every product can be maximally specific. The chance of breaking one Microsoft product by installing the package repo for a different Microsoft product is not ideal, especially because it's very hard for an everyday Linux user to tell this is going on.

[rowanmiller]

A few of us met recently to talk about consolidating all our install instructions, pre-reqs, supported versions, etc. in to a single place (in docs). cc @Thraka who is going to be working on that soon.

[carlossanlop]

@Thraka @rowanmiller when you have an issue or a PR tracking the fix for this, please share it here.

[ffes]

Note that for Ubuntu 19.10 has been released on 2019-10-17. There is no package available for download ATM.

[dagood]

I checked in an Ubuntu 19.10 docker container, and the 19.04 packages work fine there.

[carlossanlop]

Hey @dagood can we consider this issue resolved? Can you close it if true?

[dagood]

No, this issue is tracking this effort to improve the situation:

A few of us met recently to talk about consolidating all our install instructions, pre-reqs, supported versions, etc. in to a single place (in docs). cc @Thraka who is going to be working on that soon.

[rowanmiller]

FYI here is the PR associated with that work dotnet/docs#15569.

[dagood]

A few of us met recently to talk about consolidating all our install instructions, pre-reqs, supported versions, etc. in to a single place (in docs). cc Thraka who is going to be working on that soon.

FYI here is the PR associated with that work dotnet/docs#15569.

After getting a chance to look at these changes, it doesn't look like they address this thread, they just move the existing instructions so they're maintained in the docs repo. It's certainly good to know this is happening, but I misinterpreted it as a solution. My mistake not asking who "a few of us" were--with the context of the thread, I assumed the Linux repo admins, PowerShell, and the .NET Core release team.

---

So, this issue is back to tracking this:

[@leecow] I've been reluctant to chase the repo versioning when installers and dependencies are compatible across distro versions. Looking at this again to develop a plan/process for maintenance.

[jubalh]

As the original creator of this issue I would like to thank you guys for keeping at it.

[Thraka]

Sorry. that's an oversight on my part in the scramble to get the instructions ported so the website versions could be retired. But now it's easy to fix when someone spots a change just by opening a PR. @leecow is going to own these instructions and my part was to set this all up so it's easy to modify.

Once the holidays are over, I'll be able to sync with the team and figure out a formal plan for updates.

[dagood]

Not your fault IMO, just a tie-in that didn't quite have enough context for me to get when I skimmed through earlier.

So, it sounds like the plan is that once the changes you're making for maintainability go through, the page will be kept up to date by @leecow with every distro version we support as they come in and go EOL. Cool.

On the release side, I remember hearing it's an issue to push the RPM/Deb packages to additional feeds and work with the Linux repo admins to keep the set of repos up to date. Is there a plan on this side, or is this actually no big deal?

(Communicating with the PowerShell folks to make sure they're set up for this is something we should also do, but I suppose we should open an issue over there to track this. Specifically, making sure they also have coverage so installing .NET Core doesn't break auto-update for PowerShell.)

[scalablecory]

@leecow has this been resolved?

[mairaw]

@leecow @adegeo can we close this one?

[leecow]

Yes, I think things are generally cleaner but there are still some instances that will roll off over time.