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
[wip] Remove binary blobs #43263
[wip] Remove binary blobs #43263
Conversation
👎 sometimes the binary versions are the only way to get certain features, and the betas are much nicer through bins. |
Hmmm... Maybe this is a good chance to make the source-based versions better? Besides branding, there should be no reason we cannot build binaries just as good as Mozilla's on Nix infrastructure. Binary blobs are just never going to be as portable as a Nix .drv. |
Binary blobs usually don’t work with Nixpkgs & are generally discouraged. tor-browser-bin & firefox-bin both have equivalent source-based derivations. We want to encourage them as much as possible.
c70ea5e
to
3f68889
Compare
No attempt on aarch64-linux (full log) The following builds were skipped because they don't evaluate on aarch64-linux: dropbox Partial log (click to expand)
|
No attempt on x86_64-darwin (full log) The following builds were skipped because they don't evaluate on x86_64-darwin: dropbox Partial log (click to expand)
|
No attempt on x86_64-linux (full log) The following builds were skipped because they don't evaluate on x86_64-linux: dropbox Partial log (click to expand)
|
Practically speaking, I can't imagine we'll want to be building all the variations of the beta / nightly releases of each of these packages on Hydra, and nobody will want to be building them locally (looking at many hours of builds). I think these bins are reasonable. I think they are valuable. edit I'm also concerned about losing possible i18n improvements the -bin FF packages provide over what we have packaged. |
The maintenance burden to maintain It's also worth noting that the I don't know about the rest of the packages in this PR but at the very least firefox and thunderbird bins should remain. |
Also, practically speaking, from time to time updating Firefox source build is a longer process than a binary release just because |
At least firefox-bin and thunderbird-bin should be kept since if a revision is broken they provide a sane way to still perform an upgrade. The other might be removed unless there is a good reason not to do this. |
The binary tensorflow was re-added because of difficulties building from source. There are good reasons to sometimes use binaries, as mentioned already by others, so I am against this change. |
Ok closing for now. This discussion is probably best for me to bring up in an RFC. |
Motivation for this change
This removes some packages that are hopefully completely unnecessary now that a source-based alternative exists for them.
Here are the names effected:
To make the transition from these easier, I think it would be good to provide some alternatives. I have added a nur-packages repo that contains the old expressions: https://github.com/matthewbauer/nur-packages
There could be a good reason for keeping these around but my understanding is that we can now use the official branding in the source-based firefox & thunderbird.