Update package guidelines for .NET Core 3.0

[tmds]

• Remove section on patch packages, sdk feature packages. I believe Microsoft, nor
  Red Hat are providing such packages for .NET Core 2.2 for non-Windows platforms.

• Rename aspnetcore-runtime package to aspnet-runtime. No one has provided such
  a package. Suggesting a shorter name.

• Add packs. Initial split:

• To reduce the number of packages, I've added Microsoft.AspNetCore.App.Ref,
  Microsoft.NETCore.App.Ref and Microsoft.NETCore.App.Host. to the sdk package.
• NETStandard.Library.Ref is a separate package because multiple .NET Core versions
  may be installed side-by-side and provide the same files.
• Microsoft.WindowsDesktop.App.Ref is currently in its own package, I'm not
  sure how it versions with the rest.

[tmds]

@nguerrera @dsplaisted @omajid ptal. This is a suggestion, please review and correct/improve.

CC @dleeapho @crummel @dagood @eerhardt @aslicerh

[dagood]

To reduce the number of packages, I've added Microsoft.AspNetCore.App.Ref,
Microsoft.NETCore.App.Ref and Microsoft.NETCore.App.Host. to the sdk package.

For the targeting pack, this breaks building for a downlevel .NET Core version with a minimal offline install. You should be able to e.g. install a 3.1 SDK and 3.0 targeting pack and build something that targets a 3.0 runtime. Targeting packs in general should be separate to support this kind of install. (Edit: Also, a targeting pack is expected to very rarely have a patch change, and it would be nice to let users keep the one they have installed when the runtime or SDK revs.)

For the app host pack, I'm not so sure--that one might be fine.

[dagood]

/cc @leecow

[tmds]

@leecow @dagood can you have a look at the doc and point out things that don't match with Microsoft packages for 3.0?

[tmds]

@omajid can you also have a look and see if things look good for you?

[dagood]

A few minor suggestions/fixes. The existence of a templates package is different from the Microsoft build--but that's discussed above and makes sense to me.

[leecow]

Should it be noted that some directories/components are available at .NET Core 3.0+?

[leecow]

nevermind ... the title of the doc is 3.0

[omajid]

A couple of questions:

• All targeting packs have the word targeting in them, except dotnet-apphost-pack. Is that intentional?

• It's possible to have multiple versioned-directories under the fxr directory. But there's only a single dotnet-hostfxr package (and without a version). Is that intentional? Will the host be backwards compatible?

• dotnet-sdk-x.y should have a dependency on dotnet-runtime-x.y too, right?

• dotnet-templates-x.y needs a dependency on dotnet-host for $DOTNET_ROOT/ directory for putting in $DOTNET_ROOT/templates/<version>, right?

[nguerrera]

All targeting packs have the word targeting in them, except dotnet-apphost-pack. Is that intentional?

Yes. Targeting packs have reference assemblies, apphost packs have the apphost template. apphost and targeting are mutually exclusive pack categories.

It's possible to have multiple versioned-directories under the fxr directory. But there's only a single dotnet-hostfxr package (and without a version). Is that intentional? Will the host be backwards compatible?

Only the latest fxr directory is actually used. Yes, it always has to be backwards compatible. I believe the versioning is mostly to be able to lay down a newer one in some scenarios where the older one is locked and not require a reboot. I imagine this isn't an issue for Linux. cc @vitek-karas

[dagood]

• It's possible to have multiple versioned-directories under the fxr directory. But there's only a single dotnet-hostfxr package (and without a version). Is that intentional? Will the host be backwards compatible?

The Microsoft build does include -x.y, from my table in #13196 (comment):

Name	Version	Release	Requires
dotnet-hostfxr-3.0	3.0.0	0.1.preview6_27804_01	dotnet-host

I don't think there's any reason to have this different between Microsoft builds and the packaging guidelines. (Although yeah, there might not be a big reason to keep it the same.)

• dotnet-sdk-x.y should have a dependency on dotnet-runtime-x.y too, right?

👍

• dotnet-templates-x.y needs a dependency on dotnet-host for $DOTNET_ROOT/ directory for putting in $DOTNET_ROOT/templates/<version>, right?

Aren't directories automatically created to suit whatever files a package wants to install? AFAIK there's no env var set or needed, if that's what you're saying.

[omajid]

Aren't directories automatically created to suit whatever files a package wants to install? AFAIK there's no env var set or needed, if that's what you're saying.

Sorry about the confusion.

In a distribution like Fedora, each package has to say which files/directories it owns and which one should be created by another. Templates use (say) /usr/lib/dotnet/templates. But who creates /usr/lib/dotnet/? That can be created/owned by dotnet-templates-3.0 package, or dotnet-templates-3.0 can say it needs a dotnet-host package to provide /usr/lib/dotnet/ under which templates can be installed. It seems to me like a dependency on some version of dotnet-host makes sense. What do you think?

[dagood]

I see, that sounds reasonable to me. I don't know any situation it's useful to have templates without a host. (Or really, without an SDK... but the SDK depends on the templates so AFAIK we have to pick the dependency that's more useful.)

[tmds]

The Microsoft build does include -x.y, from my table in dotnet/dnceng#1317 (comment):

I'll update this in a follow-up PR. I had kept the hostfxr package as it was. Multiple versions aren't needed on Linux, but I'll add it to align with the Microsoft build.

dotnet-sdk-x.y should have a dependency on dotnet-runtime-x.y too, right?

There is a dependency via the aspnetcore runtime, but we can add a direct one too.

In a distribution like Fedora, each package has to say which files/directories it owns and which one should be created by another. Templates use (say) /usr/lib/dotnet/templates. But who creates /usr/lib/dotnet/? That can be created/owned by dotnet-templates-3.0 package, or dotnet-templates-3.0 can say it needs a dotnet-host package to provide /usr/lib/dotnet/ under which templates can be installed. It seems to me like a dependency on some version of dotnet-host makes sense. What do you think?

Does this apply to more than templates?
For example, if I side by side install 2.1.508 and 2.2.108 sdk. It's clear the versioned folder /usr/lib64/dotnet/sdk/2.1.508 is owned by the 2.1 sdk package. Who owns the parent (/usr/lib64/dotnet/sdk)?

[omajid]

For example, if I side by side install 2.1.508 and 2.2.108 sdk. It's clear the versioned folder (e.g. /usr/lib64/dotnet/sdk/2.1.508) is owned by the sdk package. Who owns the parent (/usr/lib64/dotnet/sdk)?

For Fedora packages, I have set things up so each sdk owns /usr/lib64/dotnet/sdk (along with /usr/lib64/dotnet/sdk/<version>). Multiple packages can own a directory.

[tmds]

For Fedora packages, I have set things up so each sdk owns /usr/lib64/dotnet/sdk (along with /usr/lib64/dotnet/sdk/)

I see.

The packs are in the same situation as the templates? Because they don't have dependencies?

[omajid]

The packs are in the same situation as the templates? Because they don't have dependencies?

Yes; at least, that's what I have done so far.