treewide: move "unstable" from version to pname #110442
Conversation
davidak
requested review from
FRidh,
jonringer and
thoughtpolice
as code owners
ofborg
bot
added
6.topic: GNOME
davidak
force-pushed
the
unstable-name
branch
from
6893e89 to
457b700
Compare
ofborg
bot
removed
the
2.status: merge conflict
davidak
force-pushed
the
unstable-name
branch
3 times, most recently
from
2750893 to
8c46cbb
Compare
There was a problem hiding this comment.
I'm not a big fan of including unsable in the pname. If I have "package a", it will still be a "package a" if I select a different release or commit. The package name should stay the same, but declare the difference through the version tag.
I wasn't around when the unstable convention began, but my guess is that it was because we didn't have a good way to distinguish between a stable or unstable release. However, I think we have better conventions now (zfs vs zfsUnstable), and the differences can be determined by the version, which could have part of the rev, date of commit, or a pre-release tag.
EDIT: Grammar
davidak
force-pushed
the
unstable-name
branch
from
8c46cbb to
9e78e45
Compare
i agree that it would make sense that pname match the upstream name, but that is currently the official documented rule i think this change was needed for repology. not sure if it is still needed @jtojnar |
davidak
force-pushed
the
unstable-name
branch
2 times, most recently
from
b5e3168 to
b979379
Compare
|
When a revision is used instead of a reference or explicit release, it not always means it corresponds to an unstable version. The |
nix-env users are already in a tough spot, even from something like many similar packages being available. For example: will get you python3.10 installed. |
so they don't get updates for installed packages, because the name does not exist anymore? that would be indeed very bad. with the current rules, that would happen every time a package switches from stable to unstable release and the other way around and i'm not sure if nix would update a package if the version changes from 0.5 to 2021-01-05 this one time i didn't question the existing rules, but it looks like i should 😬 so, how can we get to a consistent state from here. nixpkgs is a mess |
davidak
force-pushed
the
unstable-name
branch
3 times, most recently
from
9e3eb1e to
b6a6e94
Compare
according to the current rules https://nixos.org/manual/nixpkgs/stable/#sec-package-naming Also - fixed some version formatting - changed `name` to `pname` - fixed some style issues - in some cases it was needed to replace `${pname}` with the actual string, so it does not contain "unstable" - in tmux-plugins, the `pluginName` was changed - in one case (ppx_tools) the "unstable" part was lost
davidak
force-pushed
the
unstable-name
branch
from
b6a6e94 to
e19569f
Compare
|
Until we have no consent how to do this I don't think we should change it. I am still for changing nix to fit this usecase. |
Repology currently uses value
Yes, that is correct.
If
We need policy change along the lines of #100833 (comment) and #100833 (comment). That works for both |
|
Result of 69 packages marked as broken and skipped:
1219 packages failed to build:
27 packages built:
|
|
OK, pausing the work on this until we have consensus how it should be. |
|
FYI: There are already 120 packages following this convention. After this change it's 479 (unstable packages). |
|
If I had to make a rule for unstable releases, it would be E.g. would be unfortunate, another option would be, to do the current paradigm, but just drop this is what vimPlugins does already, as vim plugins usually just track the latest default branch |
|
I would not consider having We need unstable or some other tag so that repology can filter it out easily. |
|
What exactly is the problem we are trying to solve by including How about this. Last released version followed by a release date such as Pros:
Cons:
For repology, we would then presumably show as being up to date as we are > latest official release. As soon as version |
|
In case a project hasn't made a formal release ever, we could still do |
|
It is not about appearing up to date on repology. Repology uses version data from distros as a proxy for project versions so if we used version that is greater than the latest stable version and cannot be filtered out, it would actually mark other distros as outdated. That could only lead to nixpkgs being blacklisted as a whole. Also note that your proposed format is actually used by some projects for their official releases so we still would not be able to distinguish VCS snapshots from official releases. (first one I found by |
|
I think we need a new variable which tells you that the version we use is unreleased and picked from master. |
|
I think that would be even harder to push through – we would still need to teach |
|
I absolutely agree with @peterhoeg but propose following Debians model of extended version numbers and using a format along the lines of I think it would be very unfortunate if the notion of package name and version differs between Nix and Nixpkgs. It is already difficult enough to understand how things interact in the Nix ecosystem and moving away from is simply confounding when the documentation for
Edit: I would be willing to participate in, but not drive, an RFC for a change in this direction since it's been a pain point for many years. |
That would require manually reviewing hundreds of packages and researching if they have a release at all and after which version number we are currently. I don't think that is feasible. We only have the date right now and we can shuffle that together with the package name and unstable or any other string how we want. Changing pname when fetching unstable versions is not an option because pname is used in thousands of places to refer to the package name. This leaves us with two options: unstable or any other string before or after the date in the version number. Either way needs a fix in the builtin to fully function if I remember correctly. |
|
Related: #68518 |
I believe a version is only considered valid if more than one distro has the same version. Otherwise it's first considered a "unique" version. However, I think in principle we should still try to avoid polluting repology with bad information. |
Not so much. higan is outdated in almost all distros (because they changed the build system radically), but the new version was taken from... Wikidata. |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/brainstorming-for-rfc-pname-and-version/12873/1 |
|
I marked this as stale due to inactivity. → More info |
stale
bot
added
the
2.status: stale
|
Closing due to huge conflicts. |
Motivation for this change
Fix #68518
This PR mainly moves "unstable" from
versiontopname. That's how it should be according to the rules in https://nixos.org/manual/nixpkgs/unstable/#sec-package-namingAlso
nametopname${pname}with the actual string, so it does not contain "unstable"pluginNamewas changed. i don't know what issues that could cause. can the plugins still be installed?I have done everything with some shell magic and reviewed every single file and did some manual clean ups.
Since the name attribute was not changed in most cases, this should not trigger a mass rebuild to my understanding.
Please review carefully as this could cause a lot of trouble. I'm still brave enough to try it.
Things done
i'm testing it right now and fixing issues
sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)nix path-info -Sbefore and after)