-
-
Notifications
You must be signed in to change notification settings - Fork 14.8k
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
gnomeExtensions: add patch framework and fix extensions #137131
Conversation
It's like Haskell's overlay system, but way more primitive. We simply pre-define some package overrides that are required for an automatically packaged extension to work. Ideally, all (or almost all) currently manually pacakged extensions will work this way. Since these are mostly just a few lines each, there is no need to split this up into a lot of small files.
@jtojnar I'd like to know your opinion about my approach to patching extensions. Generally it is the right move forward, as it will make manual packaging like #134789 obsolete. Having patches on top of automatic packaging means that maintainers don't have to manually track updates. My main open question however is how should we deal with patches that are more than just a few lines, especially those that require actual patch files (instead of |
Result of 380 packages built successfully:
4 suggestions:
|
This looks good to me. It should work fine with patch files too and I would say the usual advice on choosing files vs. |
My convention proposal for patches with more than one file:
|
We want the pname to match a potential automatic packaging (if the extension is updated to support a more recent GNOME version) as closely as possible.
I think this is a good change. Setting the install phase and using dontBuild gives us the most flexibility and minimizes surprises for people stumbling over this. I am not totally convinced by the filename |
1192232
to
49041cd
Compare
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/easy-way-to-add-paths-to-gi-typelib-path/15240/2 |
If no one else merges or raises concerns, I will merge this in 48h. Please ping me, if I forget. |
{ | ||
lib, | ||
ddcutil, | ||
gjs, | ||
}: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
{ | |
lib, | |
ddcutil, | |
gjs, | |
}: | |
{ lib | |
, ddcutil | |
, gjs | |
}: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we had this discussion more than once in the past. Until nixpkgs settles on some coding style that is enforced automatically, I will keep it like this.
mkdir -p $out/share/gnome-shell/extensions/ | ||
cp -r -T $src $out/share/gnome-shell/extensions/${uuid} | ||
cp -r -T . $out/share/gnome-shell/extensions/${uuid} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not use install?
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/easy-way-to-add-paths-to-gi-typelib-path/15240/4 |
Motivation for this change
Fixes #136111 and #136112. @chrisportela please give it a try.
Things done
sandbox = true
set innix.conf
? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)