search

NixOS / nixpkgs

Nix Packages collection & NixOS
MIT License
18.06k stars 14.04k forks source link

Incorrect packages names or versions according to repology #68531

Closed jtojnar closed 4 years ago

jtojnar commented 5 years ago

The following https://github.com/repology/repology-rules refer specifically to incorrect packages in Nixpkgs. We should evaluate why we have incorrect information in each of the cases and then carry out a collection.

teto commented 5 years ago

as for luarocks-nix it's a fork of luarocks, the name doesn't matter much as it's supposed to be used only in nixpkgs. Not sure what to do to solve the issue but let me know.

jtojnar commented 5 years ago

That one is marked as a flavor, not incorrect or ignored, so we probably do not mind.

ryantm commented 5 years ago

On the NixOS office hours https://www.youtube.com/watch?v=siR3pvmxFlU , I noticed that @worldofpeace wants to move "unstable" from version to pname in derivations. I feel like the "unstable" is really part of the version, not the package name, so maybe this should be solved at the level of the website JSON generator and not at the derivation level.

worldofpeace commented 5 years ago

I think I looked at the wrong issue @ryantm. See https://github.com/NixOS/nixpkgs/issues/68518

worldofpeace commented 5 years ago

Great summary @volth.

jonringer commented 5 years ago

This makes me believe that we should have a different mechanism to capture that the source is not part of an official release, maybe something to the effect of:

  pname = "foo";
  version = "2019-10-07";
  unstable = true;

and in the construction of name in mkDerivation:


name = attrs.name or "${attrs.pname}${lib.optionalString unstable "-unstable"}-${attrs.version}";
ryantm commented 5 years ago

Instead of unstable maybe unofficialRelease?

jonringer commented 5 years ago

that seems like a more meaningful name than unstable

jonringer commented 5 years ago

would you also advocate for

name = attrs.name or "${attrs.pname}${lib.optionalString unofficialRelease "-unofficial"}-${attrs.version}";

as well? seems like it would be more aligned, even though a larger break from the pre-existing unstable paradigm

jtojnar commented 5 years ago

unofficialRelease sounds good, we might also want to add variant https://github.com/repology/repology-updater/issues/854#issuecomment-530515318

bb010g commented 5 years ago

I like variant.

teto commented 5 years ago

would it be useful to have this field report "outdated" as well ? For instance we have many love packages:

  love_0_7 = callPackage ../development/interpreters/love/0.7.nix { lua=lua5_1; };
  love_0_8 = callPackage ../development/interpreters/love/0.8.nix { lua=lua5_1; };
  love_0_9 = callPackage ../development/interpreters/love/0.9.nix { };

0_7 and 0_8 could be marked "outdated" (by 0_9).

I don't think it is but I prefer to mention it now.

jtojnar commented 5 years ago

I do not think it makes sense to report outdated status in the name field. First, we would have to change the name of every love package when a new one is added. And second, it should be possible to determine the status by checking the set of tuples pname * version.

bb010g commented 5 years ago

It might be a useful meta attribute though, like a weaker broken that tools could warn about.

domenkozar commented 4 years ago

Probably best to create a new issue with refreshed data.