doc: Document Platform Support Tiers #245368
Conversation
github-actions
bot
added
the
8.has: documentation
| platform-compatible package in Nixpkgs must successfully build in the Hydra and OfBorg CIs. | ||
| **TODO**: this seems to not be entirely true for Hydra, but true for OfBorg. | ||
|
|
||
| - `x86_64-linux`, `gcc` + `glibc` |
There was a problem hiding this comment.
Should these be tables?
There was a problem hiding this comment.
If we start with «copy what needs to be copied», let's keep RFC formatting. Then reformatting different parts of the text can be done at its own pace
| ## Tier 2 {#platform-support-tier-2} | ||
|
|
||
| Many of the packages are required to build successfully on these platforms in CI, the rest are supported on a best-effort basis by dedicated platform maintainers. | ||
| **TODO**: link teams |
There was a problem hiding this comment.
Problem is that the @NixOS/aarch64-maintainers mandated by the RFC was never created
There was a problem hiding this comment.
|
|
||
| No current support, but previous support or clear path to add support. | ||
|
|
||
| - `aarch64-darwin` |
There was a problem hiding this comment.
This seems to be false now, since OfBorg builds for this platform.
There was a problem hiding this comment.
Yes, it looks like right now after all the work done, two macOS versions are mostly on par (although capacity issues at ofBorg make it questionable if aarch64-linux has tooling of «a bit better than T3» but not really «almost T2»). And upstream pretends that the latter is the continuation of the former in some sense.
There was a problem hiding this comment.
I'm inclined towards leaving this at the state it was when the RFC was accepted, since I don't have the resources to update the list on my own.
The RFC also requires documentation be kept up to date, so that could be the next step (and the task of the respective arch maintainers) once this is merged.
There was a problem hiding this comment.
I'm inclined towards leaving this at the state it was when the RFC was accepted, since I don't have the resources to update the list on my own.
In that case you should probably close this PR.
Adding inaccurate data to the documentation is not helpful.
There was a problem hiding this comment.
Well, it's inaccurate until someone fixes it, and seeing how nothing has happened in 3 years, this PR might at least get some things moving.
There was a problem hiding this comment.
But let's see if we gather more up to date info with this PR. Thank you for your contributions to that end.
|
|
||
| ## Further reading {#platform-support-tiers-further-reading} | ||
|
|
||
| For a formal definition of platform support tiers, see [RFC046](https://github.com/7c6f434c/rfcs/blob/platform-support-tiers/rfcs/0046-platform-support-tiers.md). |
There was a problem hiding this comment.
I think it is better to include the definition in the manual: then small technical cleanups of the description can be made on the basis of technical review + not changing the intent of RFC.
There was a problem hiding this comment.
What definition would you add here then?
There was a problem hiding this comment.
I would stupidly add lines 55 to 275 from the RFC. This definitely covers «definition of support tiers» (and at least a half of it is definitely necessary). If this PR is «copy what RFC calls to copy» and updates (including formatting) are the next step, I think this is a reasonable way to handle definitions.
ofborg
bot
added
10.rebuild-darwin: 0
| @@ -0,0 +1,88 @@ | |||
| # Platform Support Tiers {#platform-support-tiers} | |||
There was a problem hiding this comment.
| # Platform Support Tiers {#platform-support-tiers} | |
| # Non-normative Platform Support Tiers {#platform-support-tiers} |
The RFC specifies these as "non-normative" (and also nearly four years out of date at this point).
|
|
||
| A small number of packages might build successfully on these platforms. | ||
|
|
||
| - `x86_64-linux`, `gcc`+`glibc` — static |
There was a problem hiding this comment.
I'm not sure this is correct. I don't think static linking is truly possible with glibc.
There was a problem hiding this comment.
@7c6f434c what do you say?
There was a problem hiding this comment.
We do have something that claims to be static linking with glibc. I am not sure which of the, say, NSS things it ends up doing with dynamic linking, but it does seem to link statically some stuff? As there are packages that depend on glibc.static, I tried to describe this build configuration as a platform…
Co-authored-by: Adam Joseph <54836058+amjoseph-nixpkgs@users.noreply.github.com>
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-08-03-documentation-team-meeting-notes-69/31263/1 |
This commit adds minimal documentation of the supported platforms. More exhaustive documentation would require producing a list of platforms for each of the 7 tiers. This was attempted in NixOS#245368, but it quickly became clear that that would be a long-term effort. In the meantime, this commit adds the most important information to the manual. Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
|
Closing in favor of #254741 |
As required by RFC046.
Closes #244686
cc @7c6f434c
Description of changes
Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)