Additional meta-information conventions

[deliciouslytyped]

I've had ideas for additional fields that would be nice to have in the meta attribute, but I forgot to make an issue at the time, I'll update this if I can remember anything. I tried to find if there were any RFCs or existing issues for such things but I didn't find any, please crosslink!

Currently I'm thinking it would be nice if there was a field where I could put URLs to references (or a description string, or whatever) for packagers that have information on packaging something. For example compilation/installation instructions, etc.

Another thing would be an attribute for linking to the official documentation of a package. This could also be nice in that when looking at something on https://nixos.org/nixos/packages.html there could be a directly clickable link for accessing documentation.

[deliciouslytyped]

I'm currently reading the Unix Haters Handbook.

• Information about incomplete packaging, hasmanpages, etc (would also allow for some automated todo lists)

[deliciouslytyped]

@infinisil had some ideas about tagging for handling nixpkgs categories.

[deliciouslytyped]

#45269 something something "possible" dependencies

[deliciouslytyped]

CVE information

[deliciouslytyped]

Path(s) to the main executable(s?) if there are any? Would allow a shorthand for something like nix-shell -p python --run python for example.

Additional "usage" information similarly?

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/concepts-for-attaching-metadata-to-nixpkgs/5632/1

[deliciouslytyped]

Pointing to packages that "obsolete" "old" "unmaintained" packages, but are not blessed forks, or something like that; e.g. scantailor-advanced seems to be a version of scantailor that's more actively developed.

[deliciouslytyped]

NixOS/rfcs#51 (comment)
Volunteer testers for packages

[timokau]

This goes back to another idea I've floated a couple of times: Extending the maintainers field to include support levels. This could reach from "I wrote this, use this, test this and will immediately respond to issues" to "I want to be notified of changes".

That could then also be used to segregate nixpkgs into "core" (everything with sufficient maintainer commitment) and "rest" ("AUR") without actually splitting up the repo. People might be more willing to add themselves to the maintainers list when the commitment is clearly defined.

[deliciouslytyped]

when the commitment is clearly defined.

• or lack thereof

[deliciouslytyped]

There should be an attribute where NixOS configuration attributes that belong to a package can be specified.
This would be good because currently there is no way to create a relationship from a nixpkgs package to services that depend on it, or conversely to hint to users that using some packages may require enabling a service or changing system security configuration. Examples of these would be some of the appname.enable settings.

[stale]

I marked this as stale due to inactivity. → More info

[deliciouslytyped]

#120692 has mainProgram at least.

I think this should have been a list, with the first item being the "main" program, or otherwise some data structure that can have all the relevant runnables listed, with a special field for the main one.

[stale]

I marked this as stale due to inactivity. → More info