[RFC 0185] Redistribute redistributable software #185
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,108 @@ | ||
| --- | ||
| feature: redistribute-redistributable | ||
| start-date: 2024-12-15 | ||
| author: Ekleog | ||
| co-authors: (find a buddy later to help out with the RFC) | ||
| shepherd-team: (names, to be nominated and accepted by RFC steering committee) | ||
| shepherd-leader: (name to be appointed by RFC steering committee) | ||
| related-issues: https://github.com/NixOS/nixpkgs/issues/83884 | ||
| --- | ||
|
|
||
| # Summary | ||
| [summary]: #summary | ||
|
|
||
| Make Hydra build and provide all redistributable software. | ||
|
|
||
| # Motivation | ||
| [motivation]: #motivation | ||
|
|
||
| Currently, Hydra builds only free software and unfree redistributable firmware. | ||
Ekleog marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| This means that unfree redistributable software needs to be rebuilt by all the users. | ||
| For example, using MongoDB on a Raspberry Pi 4 (aarch64, which otherwise has access to hydra's cache) takes literally days and huge amounts of swap. | ||
|
|
||
| Hydra could provide builds for unfree redistributable software, at minimal added costs. | ||
| This would make life much better for users of such software. | ||
| Especially when the software is still source-available even without being free software, like MongoDB. | ||
|
Comment on lines
+20
to
+25
Member
There was a problem hiding this comment. If the intent isn’t to commit to providing any specific package then I think using a concrete example of MongoDB in the motivation section is misleading, as accepting this RFC does not necessarily mean that this motivation will be addressed. |
||
|
|
||
| # Detailed design | ||
| [design]: #detailed-design | ||
|
|
||
| Hydra will build all packages with licenses for which `redistributable = true`. | ||
|
|
||
| # Examples and Interactions | ||
| [examples-and-interactions]: #examples-and-interactions | ||
|
|
||
|
Member
There was a problem hiding this comment. Just want to make sure some particular expectations are managed: While we're working on staging-next, we're looking at Hydra to identify regressions and fix them before staging-next is merged to master. With this change, there will be new Hydra jobs for non-free packages. The license terms of those packages could make it difficult or outright prevent us doing things to fix them, or even to try to reproduce locally, so it's not going to be possible in the general case to give these packages the same level of protection from regressions as we try to give free packages. So it should be understood that even though these packages are now built by Hydra and available in the binary cache, they shouldn't be expected to be any less likely to be broken by the staging process (or other PRs) than they currently are.
Member
There was a problem hiding this comment. Just want to make sure some particular expectations are managed: While we're working on staging-next, we're looking at Hydra to identify regressions and fix them before staging-next is merged to master. With this change, there will be new Hydra jobs for non-free packages. The license terms of those packages could make it difficult or outright prevent us doing things to fix them, or even to try to reproduce locally, so it's not going to be possible in the general case to give these packages the same level of protection from regressions as we try to give free packages. So it should be understood that even though these packages are now built by Hydra and available in the binary cache, they shouldn't be expected to be any less likely to be broken by the staging process (or other PRs) than they currently are.
Member
There was a problem hiding this comment. Hopefully (and by intention) the |
||
| With this change, Hydra will start building, among others: | ||
| - CUDA | ||
| - DragonflyDB | ||
| - MongoDB | ||
| - Nomad | ||
| - NVIDIA drivers | ||
| - Outline | ||
| - SurrealDB | ||
| - TeamSpeak | ||
| - Terraform | ||
| - Unrar | ||
Ekleog marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - Vagrant | ||
|
|
||
| Hydra will keep not building, among others: | ||
| - CompCert | ||
| - DataBricks | ||
| - Elasticsearch | ||
| - GeoGebra | ||
| - Widevine CDM | ||
Ekleog marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| # Drawbacks | ||
| [drawbacks]: #drawbacks | ||
|
|
||
| The only previously listed drawback is that NixOS could end up including unfree software in the ISO image without noticing. | ||
| However, as there is already unfree firmware, this fight is already half-lost. | ||
Ekleog marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| Also, adding unfree software to the ISO image would still require a NixOS maintainer to actually add it there. | ||
| The only benefit we currently get out of not building unfree redistributable software, is that the hydra builds for the ISO would fail if someone were to make a mistake. | ||
Ekleog marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| # Alternatives | ||
| [alternatives]: #alternatives | ||
|
|
||
| ### Having Hydra actually only build FOSS derivations, not even unfree redistributable firmware | ||
|
|
||
| This would likely break many installation scenarios, but would bring us to a consistent ethical standpoint, though it's not mine. | ||
|
|
||
| ### Keeping the statu quo | ||
Ekleog marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| This results in very long builds for lots of software, as exhibited by the number of years people have been complaining about it. | ||
|
|
||
| ### Implementing this RFC | ||
|
|
||
| See above for the details | ||
Ekleog marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| ### Implementing this RFC, plus adding a check on Hydra to validate no unfree software enters the ISO image | ||
Ekleog marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| This would likely be harder to implement. | ||
| It could be a job override, that would make hydra allow unfree redistributable software for all jobs except for the ISO image, which would only allow unfree redistributable firmware. | ||
|
|
||
| The drawback of this alternative is that it would be more effort to implement, especially as manpower around Hydra is very scarce and limited. | ||
Ekleog marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| However, it would solve the only previously listed drawback. | ||
|
|
||
| ### Building all software, including unfree non-redistributable software | ||
|
|
||
| This is quite obviously illegal, and thus not an option. | ||
|
|
||
| # Prior art | ||
| [prior-art]: #prior-art | ||
|
|
||
| According to [this discussion](https://github.com/NixOS/nixpkgs/issues/83433), the current statu quo dates back to the 20.03 release meeting. | ||
Ekleog marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| More than four years have passed, and it is likely worth rekindling this discussion, especially now that we actually have a Steering Committee. | ||
|
|
||
| Recent exchanges have been happening in [this issue](https://github.com/NixOS/nixpkgs/issues/83884). | ||
|
Member
There was a problem hiding this comment. For context, we also started building all the redistribuable+unfree packages in the nix-community sister project. See all the unfree-redis* jobsets here: https://hydra.nix-community.org/project/nixpkgs The jobset is defined in nixpkgs to make upstreaming easier: If this RFC passes it will be even better as users don't necessarily know about or want to trust a secondary cache.
Member
Author
There was a problem hiding this comment. That's great to know, thank you! Though we may need to do a bit more to properly handle the "cannot be run on hydra" point that was raised above. I can already see on the hydra link you sent that eval takes <1min, so should be a negligible addition to hydra's current eval times. Build times seem to take ~half a day. AFAIU there's a single machine running the jobs. If I read correctly, hydra currently has ~5 builders, and one trunk-combined build takes ~1 day. So it means that the build times would increase by at most ~10%, and probably less considering that there is probably duplication between what the nix-community hydra builds and what nixos' hydra is already building. I'm also not taking into account machine performance, which is probably stronger on nixos' hydra than nix-community's hydra. I think this means eval/build times are things we can reasonably live with, and if we get any surprise we can always rollback. There's just one thing I can't find in the links you sent to properly adjust the unresolved questions: do you know how large one build closure is on nix-community's hydra? I don't know how to get it on nixos' hydra either but it'd still help confirm there's zero risk.
Member
There was a problem hiding this comment.
Yes, especially since the way the unfree-redis jobset is put together is by evaluating and filtering trough all the nixpkgs derivations. So most likely the combined eval time is much smaller than the addition of both.
The best I can think of is to build a script that takes all the successful store paths, pulls them from the cache, runs
Member
Author
There was a problem hiding this comment. Thank you for your answer! I actually more or less found the answer from Hydra's UI. Here is my script: curl https://hydra.nix-community.org/jobset/nixpkgs/cuda/channel/latest > hydra-jobs
cat hydra-jobs | grep '<td><a href="https://hydra.nix-community.org/build/' | cut -d '"' -f 2 > job-urls
for u in $(cat job-urls); curl "$u" 2>/dev/null | grep -A 1 'Output size' | tail -n 1 | cut -d '>' -f 2 >> job-sizes; wc -l < job-sizes | head -c -1; echo -n " / "; wc -l < job-urls; end
awk '{sum += $1} END {print sum}' job-sizes
# NVidia kernel packages take ~1.3GiB each and there are 334-164 = 170
# Total: 215G, so 45G without NVidia kernel packagesI got the following results:
Unfortunately I cannot run the same test on NixOS' hydra, considering that it disabled the channels API. I just updated the RFC with these numbers, it might make sense to not build all of cuda on hydra at first, considering the literally hundreds of duplicated above-1G derivations :)
Member
There was a problem hiding this comment. So with the current Hydra workflows I'd estimate that very roughly as uploading 2 TB per month to S3. (we rebuild stuff) Except that we upload compressed NARs, so it would be less.
Member
Author
There was a problem hiding this comment. Do I understand correctly, that it'd be reasonable to do the following?
Member
There was a problem hiding this comment. I don't know. To me it doesn't even feel like a technical question. (3. is WIP so far, I think. There's no removal from cache.nixos.org yet.) |
||
|
|
||
| # Unresolved questions | ||
| [unresolved]: #unresolved-questions | ||
|
|
||
| None. | ||
|
|
||
| # Future work | ||
| [future]: #future-work | ||
|
|
||
| If this RFC lands as-is, future work could be around adding the check on hydra listed in the alternatives section. | ||
| This would validate that no unfree redistributable software enters the ISO image. | ||
Uh oh!
There was an error while loading. Please reload this page.