chromium: allow for user-provided (`.overrideAttrs`) out-of-tree patches to be passed to chromium-unwrapped

filakhtov commented 6 months ago

👋🏻 happy holiday season everyone! 🎄

Describe the bug

It is currently impossible to apply any custom patches to chromium source code due to how its derivation structured - it is a wrapper around another "unwrapped" derivation that can't be influenced directly.

Steps To Reproduce

Steps to reproduce the behavior:

Trying the usual overlay approach of

(self: super: {
  chromium = super.chromium.overrideAttrs(old: {
    patches = (old.patches or []) ++ [ "my-patch-1.patch" "my-patch-2.patch" ];
  };
})

results in patches being applied to the wrapper chromium derivation, which doesn't have a source and doesn't even run the patchPhase anyway. Getting to the unwrapped derivation is at the moment impossible.

Expected behavior

Being able to add more patches, either through the standard patches key or a custom one (like userPatches or something?).

Additional context

This holiday season I finally decided to pull the plug and switch from Gentoo to NixOS. Unfortunately I ran into the inability to apply the set of Chromium patches that I maintain. I am happy to contribute whatever fixes needed to make this supported, but would need some guidance as to the best way of approaching this.

Notify maintainers

ping @primeos @thefloweringash @networkException @emilylange 👋🏻

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

[garry@heliodor:~]$ nix-shell -p nix-info --run "nix-info -m"this path will be fetched (0.01 MiB download, 0.05 MiB unpacked):
  /nix/store/wr08yanv2bjrphhi5aai12hf2qz5kvic-stdenv-linux
copying path '/nix/store/wr08yanv2bjrphhi5aai12hf2qz5kvic-stdenv-linux' from 'https://cache.nixos.org/'...
 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.68, NixOS, 23.11 (Tapir), 23.11.20231220.d65bcea`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.1`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Add a :+1: reaction to issues you find important.

emilylange commented 6 months ago

Hmm not sure if that is currently possible.

We do expose some things, like chromium.passthru.browser (which is the -unwrapped variant) and things like chromium.passthru.mkDerivation, but not the final wrapped version.

And the final wrapped version has many instances of rec (in combination with let in) making it a nightmare to override.

All those derivations are is desperate need of refactoring anyway. But this probably ain't happening any time soon, given we are running low chromium maintainers and those that are left don't have much time rn.

You could probably patch nixpkgs out-of-tree locally and whatnot, but this isn't as... let's call it "ergonomic".

Can you elaborate on what kind of patches you want to add?

filakhtov commented 6 months ago

Thanks for your reply @emilylange

But this probably ain't happening any time soon, given we are running low chromium maintainers and those that are left don't have much time rn.

That's a very unfortunate state of things, considering the importance of the browser role in the modern days of the Internet.

All those derivations are is desperate need of refactoring anyway.

I am still in the process of learning Nix ecosystem and what patterns work best and which ones are problematic. However, I plan to dig more as I am gradually setting my system up. Are there any thoughts and ideas as to what the final state could/should look like at all? Or perhaps some of the smaller refactoring steps that can be taken in order to nudge things in the right direction and perhaps resolve the inability to patch things up? I am happy to work on something, but need guidance as to what that could look like.

You could probably patch nixpkgs out-of-tree locally and whatnot, but this isn't as... let's call it "ergonomic".

I know I can maintain a copy of nixpkgs, but I'd like to very much try and avoid doing so, because that's too much overhead. I will resort back to it if there are no other ways, but would like to first explore some other avenues.

Can you elaborate on what kind of patches you want to add?

I have a set of things that are only relevant within my homelab environment and wouldn't make sense anywhere else, otherwise I would have tried to push them at least into Gentoo's repos, or perhaps even upstream.

primeos commented 6 months ago

IIRC it is possible to override the patches - there should be existing Nixpkgs issues regarding this but unfortunately I always forget the details as I'm not overriding Chromium myself...

This came up frequently enough that I dumped some very minimal information here: https://wiki.nixos.org/wiki/Chromium#Overriding_Chromium That doesn't use overlays though.

Maybe you could try to find the previous issues regarding this? (but only if it doesn't take too much time as I'm not sure if they've been properly resolved)

AFAIK one can override more or less anything in Nixpkgs (I've seen solutions for much more complex abstractions) but it quickly get's really complex... If you find a working solution it'd be great if you could add it too the wiki and(/or) report it here. There might also be useful information on Discourse (+ you could ask there or via Matrix).

All those derivations are is desperate need of refactoring anyway.

Agreed! Chromium uses powerful abstractions but I find it too komplex as I keep forgetting how it works.

That's a very unfortunate state of things, considering the importance of the browser role in the modern days of the Internet.

Yeah, definitely... Help is always welcome though ;)

Are there any thoughts and ideas as to what the final state could/should look like at all?

Not really - I guess the main issue is that we don't know who already overrides Chromium and what functionality is required.

Or perhaps some of the smaller refactoring steps that can be taken in order to nudge things in the right direction and perhaps resolve the inability to patch things up?

A Chromium refactoring is probably not the best way to get started - I guess it would be best to start with cleanups / regular maintenance before making better changes (also helps getting familiar with the code, learning who to ping, etc.).

emilylange commented 6 months ago

This came up frequently enough that I dumped some very minimal information here: nixos.wiki/wiki/Chromium#Overriding_Chromium

From what I can tell, the way described there (using chromium.mkDerivation, shorthand for chromium.passthru.mkDerivation, mentioned in my original response) returns an -unwrapped version, not the properly wrapped one.

filakhtov commented 6 months ago

Thanks for your thoughts @primeos.

I have spent a while looking around before reporting this issue and unfortunately everything I have tried didn't work. As @emilylange pointed above, unfortunately I can't get a properly wrapped chromium derivation in the way things currently structured. So we are back to square one.

A Chromium refactoring is probably not the best way to get started - I guess it would be best to start with cleanups / regular maintenance before making better changes (also helps getting familiar with the code, learning who to ping, etc.).

I have a lot of dev experience outside of Nix, so I am sure I will be fine, I just would like to understand the direction we want to move towards. Considering the need to refactor things has been mentioned multiple times I assume people have some (perhaps vague) ideas where this should be moving and would like to hear what those ideas are. So please share any thoughts on this and let's see if I can take any steps to move us in the right direction, under your careful guidance of course.

NixOS / nixpkgs