Skip to content
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

linuxPackages: use pname and version instead of name #365953

Open
wants to merge 28 commits into
base: staging
Choose a base branch
from

Conversation

jopejoe1
Copy link
Member

Things done

  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
    • sandbox = relaxed
    • sandbox = true
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
  • Fits CONTRIBUTING.md.

Add a 👍 reaction to pull requests you find important.

@jopejoe1 jopejoe1 force-pushed the linuxPackages-pname branch from 5d5061e to a6c0b54 Compare January 17, 2025 10:03
@jopejoe1 jopejoe1 changed the base branch from master to staging January 17, 2025 10:05
@jopejoe1 jopejoe1 marked this pull request as ready for review January 17, 2025 10:05
@@ -55,7 +55,8 @@ let
];
in
stdenv.mkDerivation {
name = "broadcom-sta-${version}-${kernel.version}";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With kernel modules in particular, it's really useful to have the particular kernel version be part of their name so you can see from the failing derivation itself what kernel version they failed against.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we could make it a convention to add the kernel version to the derivation version.

i.e. version = "1.2.3-${kernel.version}";

Copy link
Contributor

@philiptaron philiptaron Jan 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like that convention, and it's going to be actually true -- the version is a tuple of the package's version and the kernel for which it's intended. Now that #234651 has landed, we could even encode that in a kernel-specific mkDerivation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only major downside of this approach could be if someone wants to use finalAttrs.version for src.rev/src.tag.

If we had a kernel-specific mkDerivation, we could maybe store a moduleVersion and kernelVersion in finalAttrs though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we had a kernel-specific mkDerivation, we could maybe store a moduleVersion and kernelVersion in finalAttrs though.

Not only that -- we could use name to write out the name of the derivation however we wanted, while still requiring the users to use pname and version. The default mkDerivation behavior of name = "${pname}-${version}" is ours to change!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants