Skip to content
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

[Packaging] Clarify how RID-specific packages for Microsoft.NetCore.App are expressed #87

Closed
terrajobst opened this Issue Oct 26, 2016 · 2 comments

Comments

Projects
None yet
3 participants
@terrajobst
Copy link
Member

terrajobst commented Oct 26, 2016

From the packaging spec:

  • No implementations
    • All implementation pieces are in RID-specific packages

@weshaggard asked:

Do we expect these to be coming in via a runtime.json file in the identity package?

@ericstj, could you make a proposal?

@ericstj

This comment has been minimized.

Copy link
Member

ericstj commented Oct 26, 2016

Here's what I'm thinking for all types of split packages.

For packages that are framework split only:

  1. Identity package contains no files other than text license/etc in the root.
  2. Identity package contains single package references for each specific framework, these packages follow the naming scheme framework.<tfm>.<packageId> where <tfm> is the specific framework that is split out and <packageId> is the id of the identity package.
  3. Split packages contain only dependencies and files for the TFM they represent. If another framework split package exists with the same target framework of higher version the lower TFM package will also have placeholder files for the future tfm and empty dependency groups for the future TFM. As such this permits them to behave correctly should they ever be unconditionally installed. (EG: in a netcoreapp2.1 project installing both a netcoreapp2.0 and netcoreapp2.1 framework split package directly)

For packages that are runtime split only:

  1. Identity package contains all runtime-agnostic files and dependencies of those files.
  2. Identity package will contain a runtime.json that associates the identity package with runtime-specific packages for a particular RID. Those packages will follow the naming scheme runtime.<rid>.<id>.
  3. The runtime-specific packages will contain runtime-specific files and the list the dependencies of those files. If more derived runtime-specific package exists the less-specific RID package will also contain placeholders to ensure that the runtime-specific assets do not apply to derived RIDs if that is desired. EG: win7 & win8 runtime specific packages exist, win7 package will have a placeholder for win8.

For packages that are both framework and runtime split.

  1. As above for framework split packages, but framework-specific packages only contain runtime-agnostic files and dependencies of those files.
  2. Identity package will contain a runtime.json that associates framework-specific packages with framework+runtime-specific packages for a particular rid. Those packages will follow the naming scheme runtime.<rid>.framework.<tfm>.<id>.
  3. The framework+run-time specific packages will contain the framework+runtime specific files and list the dependencies of those files. As above we'll need placeholders here to ensure correct behavior when directly installed.

Why put the runtime.json in the identity package?
Because we expect the identity package to always be part of the compile graph; in other words, in the direct closure of directly referenced packages. If we expected the identity package to only appear in a runtime-specific graph then we would need to come up with a scheme (ALA Microsoft.NETCore.Targets) to put the runtime associations in a package that was garunteed to be in the compile graph.

@weshaggard weshaggard added the packaging label Dec 2, 2016

@weshaggard weshaggard assigned terrajobst and unassigned ericstj Mar 30, 2017

@weshaggard weshaggard added documentation and removed packaging labels Mar 30, 2017

@terrajobst

This comment has been minimized.

Copy link
Member Author

terrajobst commented Mar 13, 2019

@ericstj presumably this has happened, so I'm going to close this.

@terrajobst terrajobst closed this Mar 13, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.