Add metadata to packages #190
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "add-meta"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Add meta field with license and other information to our packages.
80b42c302eto45552934424555293442toed0cda5edaed0cda5edato66df874b4aAdd meta to packages and create nix-support/private file for unfree packages + fixes for risc-v cross compileto Add meta to packages and create nix-support/private file for unfree packagesAdd meta to packages and create nix-support/private file for unfree packagesto WIP: Add meta to packages and create nix-support/private file for unfree packages66df874b4ato2c15bfd5b9WIP: Add meta to packages and create nix-support/private file for unfree packagesto Add metadata to packages2c15bfd5b9toda3d76213cda3d76213ctoec1da8f88fMaybe it would be good to write somewhere what exactly means to be put as the maintainer of a package, because they have different levels of "maintenance status". Some are broken or commented in the overlay.
@ -49,2 +49,3 @@# propagate nixpkgs lib, so we can do bscpkgs.libinherit (nixpkgs) lib;lib = nixpkgs.lib // {bsc.maintainers = import ./maintainers/maintainer-list.nix;I would move this to pkgs/maintainers.nix so that m completes to m/ and it doesn't litter the root dir.
@ -123,1 +123,4 @@in bscPkgs // {lib = prev.lib // {bsc.maintainers = import ./maintainers/maintainer-list.nix;Same here, also indentation is missing one space.
@ -114,0 +115,4 @@meta = with lib; {homepage = "https://github.com/bsc-performance-tools/extrae";description = "Instrumentation framework to generate execution traces of the most used parallel runtimes";maintainers = with maintainers.bsc; [ rarias ];I think we can leave this one unmaintained, and maybe set the broken=true flag.
@ -104,0 +105,4 @@meta = with lib; {homepage = "https://www.intel.com/content/www/us/en/developer/tools/overview.html";description = "Intel compiler";This one is only Intel MPI
@ -89,0 +93,4 @@description = "nix bubblewrap wrapper";maintainers = with lib.maintainers.bsc; [ rarias ];platforms = lib.platforms.linux;license = lib.licenses.gpl3Plus; # TODO: license?You can use MIT as it was the original license we had in bscpkgs. Also this is likely unmaintaned + broken.
@ -18,0 +22,4 @@description = "nix bubblewrap wrapper";maintainers = with lib.maintainers.bsc; [ rarias ];platforms = lib.platforms.linux;license = lib.licenses.gpl3Plus; # TODO: license?I didn't put one, can it be left unset?
Sure, but we will later have to decide the default behavior for unset licenses if we do the nix-support/private for the cache.
For this one is okay as rebuilding it is fast. I think I can use MIT but I need to check how I wrote that. We probably want to avoid distributing packages without a license or with a non-redistributable license. Maybe a
meta.redistributable = falseattribute is easier, as unfree doesn't necessary mean non-redistributable.I'll leave it empty for now.
licenses are attribute sets with
{unfree, redistributable::Bool, ...}we can either check for unfree or redistributable later on.@ -62,0 +63,4 @@meta = {homepage = "https://gitlab.bsc.es/nos-v/nos-v";description = "Tasking library enables the co-execution of multiple applications with system-wide scheduling and a centralized management of resources";maintainers = with lib.maintainers.bsc; [ abonerib ];I would need to review changes in nosv as well as it affects ovni, so you may add me as well as maintainer.
ec1da8f88fto5dfa211f085dfa211f08to4b4e6e93274b4e6e9327toed8d6d1ec7ed8d6d1ec7to5d861077b45d861077b4todd7744358fI think we can do something similar to what is done with nixpkgs maintainers:
Mainly, a maintainer should be expected to keep up with the updates of the package and should be pinged in Gitea when someone proposes a change in the package so they can test it.
Additionally, if we decide to use hydra, maintainers could opt-in to get notified of build failures for their packages.
dd7744358ftoe9754aa8d7That seems reasonable, is mostly what we currently do already. It might be good to write this in a similar
doc/maintainers.mddoc file linking to that nixpkgs section.I'm okay maintaining the last release of OmpSs-2 packages, as that only happens twice a year. But I don't think I would be ok making them for each commit that lands on master of each project. I would accept patches though.
I have added documentation addressing these points, hopefully it's clear enough.
Thanks, looks great!
f8ab42813dto4685c36e2f