unstable part of version instead of pname #68518
Comments
jtojnar
added
0.kind: bug
|
But even with this scheme |
|
Repology can mark packages ending with unstable as ignored (light gray). |
jtojnar
added
9.needs: documentation
and removed
0.kind: bug
|
The main issue with where to place unstable probably comes from the fact that we use it for two different things:
Nix makes it hard to tell which is which since it does not know any blessed attributes other than name, and |
jtojnar
removed
the
3.skill: sprintable
|
@jtojnar and I also talked about this on IRC #nixos-dev (note: when I say "attributes" I meant attrPath in all-packages.nix) |
|
@volth made a good summary comment about this #68531 (comment) |
|
Thank you for your contributions.
|
stale
bot
added
the
2.status: stale
|
Still unresolved. |
stale
bot
removed
the
2.status: stale
|
About this issue. I am confused. Sometimes we have a software like DWM, with a numbered official version and a git version both maintained by us. They differ by pname, not merely by version. On the other hand, we use What convention we should follow, after all? |
|
it stresses me to see that this is still not solved. we have rules, but prs following the rules are rejected because the rules are no good nixpkgs is a mess and i can't clean it up :/ maybe the RFC process could help us to decide on a rule there are arguments against unstable in pname (nix-env breakes) anyone want to bring this forward? |
It will be a sprintable job after all
And, thinking about the repology issue, unstable in pname is treated as pname, so that 'blob-unstable' is different from 'blob'.
Prefix is better. It is an important information, and putting it before the version numbering makes it clear.
youtube-dl uses dots too, but I think we can't blindly suppose no one will write its releases that way. Putting
I am merely converting everything I am touching to that format, and applying some manual cleanups |
|
So one step forward would be to create an RFC that suggests to use @AndersonTorres would you like to do that? |
|
My main concern here is about the |
|
@davidak I would like it. What can I do? |
I would say that for now we should just follow the rules, even if suboptimal. Rejecting PRs because they follow rules we do not like is terrible for the submitter.
The argument, then, is that putting it in And since
The alternative of moving the tag to the end of version as described in #100833 (comment) makes a trade-offs that need to be carefully considered. It would be okay for both
There are a few. Feel free to grep nixpkgs.
Repology can filter that out but yeah, it is not ideal.
I would say
Yeah, there are several such packages in nixpkgs.
I would say any changes until we decide on the rule are premature.
That is Eelco’s concern as well and he is very adamant about it.
The first step would probably be formulating why are the current rules not good enough. Then we can compile list of alternatives and compare them against the criteria. It would be especially useful to look at what other distros do. IIRC, Arch did something like |
|
Disadvantage would be that nix-env would not update from unstable version to stable after stabilization because year would be almost certainly greater than whatever stable major version. But that is an issue with the current rule as well – even worse, actually, since `nix-env` will consider them two different packages and will not update even with `--always` (which should [IMO](#100833 (comment)) be the default).
(That's why I sometimes give up and insert a zero component before the year so that the ordering is right)
The first step would probably be formulating why are the current rules not good enough. Then we can compile list of alternatives and compare them against the criteria. It would be especially useful to look at what other distros do. IIRC, Arch did something like `$lastStableVersion-git+$commitHash` which would solve the `parseDrvName` issue and upgrades between stable and temporarily unstable versions – but not upgrades between unstable versions without `--always` since commit hashes are not monotonous.
$lastStableVersion-unstable-$date-$hash would be so nice to have agreed…
|
No, no, no. The only problematic thing would be if some project released many modifications in Unstable/Trunk/Master/Main/WTH branch in a single day. and therefore date would not be unambiguous. But we can use the last commit of yesterday if we are to be overly cautious. I liked that idea! What you all think?
I would say ambiguity is the issue here. Many possibilities and no uniformity.
My current stance is
IIANW, it is mostly from AUR. Anyway I think the model above captures the intent well enough. |
Yes, that's why date should be before the hash! But I do not insist on hash and will support the no-hash version if you write an RFC or a PR to the manual |
|
This issue 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 like the idea of |
|
I will upload a RFC shortly. |
|
As promised: |
|
I marked this as stale due to inactivity. → More info |
stale
bot
added
the
2.status: stale
|
Is #234201 merging enough to close this issue? |
stale
bot
removed
the
2.status: stale
|
The issue will persist until the packages switch to the new convention. |
|
And probably also support code like https://github.com/NixOS/nixpkgs/blob/3a1e7765172c444c348dde552ab4fa549ef59b27/pkgs/common-updater/unstable-updater.nix. |
samueldr
added
the
5. scope: tracking
As discussed in repology/repology-updater#854 (comment), in many packages we currently have unstable a part of
version, rather thanpnamesuggested in https://nixos.org/nixpkgs/manual/#sec-package-naming. I know I am guilty of promulgating this and we should probably fix that before switching Repology topname&version.The documentation should probably be clarified re this.
cc @volth @worldofpeace
The text was updated successfully, but these errors were encountered: