Open jtojnar opened 4 years ago
worldofpeace
commented
4 years ago But even with this scheme pname won't be the upstream name. Is the rule even desirable?
What does repology do to consider package version which are commits off the source repo?
jtojnar
commented
4 years ago Repology can mark packages ending with unstable as ignored (light gray).
jtojnar
commented
4 years ago The main issue with where to place unstable probably comes from the fact that we use it for two different things:
pnameversionNix makes it hard to tell which is which since it does not know any blessed attributes other than name, and parseDrvName only recognizes the first case.
worldofpeace
commented
4 years ago @jtojnar and I also talked about this on IRC #nixos-dev
(note: when I say "attributes" I meant attrPath in all-packages.nix)
ryantm
commented
4 years ago @volth made a good summary comment about this https://github.com/NixOS/nixpkgs/issues/68531#issuecomment-533760929
stale[bot]
commented
4 years ago Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly:
jtojnar
commented
4 years ago Still unresolved.
stale[bot]
commented
3 years ago I marked this as stale due to inactivity. → More info
davidak
commented
3 years ago The initial issue lists 164 affected issues. Now it seem to be 395.
[davidak@gaming:~/code/nixpkgs]$ egrep -R "version.+=.+unstable" pkgs/ | wc -l
395I will look into it.
AndersonTorres
commented
3 years ago 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 version = unstable-${fancy-date} in other cases like this.
What convention we should follow, after all?
davidak
commented
3 years ago 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) if unstable is better a prefix or suffx to version might be subjective, so we might just vote what feels better if we don't find objective arguments... maybe we can remove unstable alltogether because YYYY-MM-DD is clearly not an official release (is there a case where it is? https://calver.org/ uses dots)
anyone want to bring this forward?
AndersonTorres
commented
3 years ago nixpkgs is a mess and i can't clean it up :/
It will be a sprintable job after all
there are arguments against unstable in pname (nix-env breakes)
And, thinking about the repology issue, unstable in pname is treated as pname, so that 'blob-unstable' is different from 'blob'.
if unstable is better a prefix or suffx to version might be subjective, so we might just vote what feels better if we don't find objective arguments...
Prefix is better. It is an important information, and putting it before the version numbering makes it clear.
maybe we can remove unstable alltogether because YYYY-MM-DD is clearly not an official release (is there a case where it is? https://calver.org/ uses dots)
youtube-dl uses dots too, but I think we can't blindly suppose no one will write its releases that way. Putting unstable-YYYY-MM-DD makes it unambiguous.
anyone want to bring this forward?
I am merely converting everything I am touching to that format, and applying some manual cleanups
davidak
commented
3 years ago So one step forward would be to create an RFC that suggests to use version = "unstable-YYYY-MM-DD"; and see if it will be accepted. Add a conclusion from all the discussions here.
@AndersonTorres would you like to do that?
AndersonTorres
commented
3 years ago My main concern here is about the parseDrvName issue. The way they are written now, version can't include unstable on it.
AndersonTorres
commented
3 years ago @davidak I would like it. What can I do?
jtojnar
commented
3 years ago 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
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.
there are arguments against unstable in pname (nix-env breakes)
nix-env does not care whether unstable tag is at the end of pname or at the beginning of version, it takes the resulting name and runs parseDrvName on it.
The argument, then, is that putting it in version is wrong because pname and version attributes will no longer match parseDrvName name.
And since nix-env uses parseDrvName, even if we moved the tag to version, Repology would still not be able to make use of it. I opened https://github.com/NixOS/nix/pull/4463 to make nix-env aware of the widely used convention of separate pname and version attributes but it has not been well received by the powers that be.
if unstable is better a prefix or suffx to version might be subjective, so we might just vote what feels better if we don't find objective arguments...
The alternative of moving the tag to the end of version as described in https://github.com/NixOS/nixpkgs/pull/100833#issuecomment-712541325 makes a trade-offs that need to be carefully considered. It would be okay for both parseDrvName and clarity. 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 be the default).
because YYYY-MM-DD is clearly not an official release (is there a case where it is? https://calver.org/ uses dots)
There are a few. Feel free to grep nixpkgs.
And, thinking about the repology issue, unstable in pname is treated as pname, so that 'blob-unstable' is different from 'blob'.
Repology can filter that out but yeah, it is not ideal.
if unstable is better a prefix or suffx to version might be subjective, so we might just vote what feels better if we don't find objective arguments...
Prefix is better. It is an important information, and putting it before the version numbering makes it clear.
I would say version is short enough that it will be clear either way. Putting it after has benefit of attributes being consistent with parseDrvName.
maybe we can remove unstable alltogether because YYYY-MM-DD is clearly not an official release (is there a case where it is? calver.org uses dots)
youtube-dl uses dots too, but I think we can't blindly suppose no one will write its releases that way. Putting
unstable-YYYY-MM-DDmakes it unambiguous.
Yeah, there are several such packages in nixpkgs.
anyone want to bring this forward?
I am merely converting everything I am touching to that format, and applying some manual cleanups
I would say any changes until we decide on the rule are premature.
So one step forward would be to create an RFC that suggests to use
version = "unstable-YYYY-MM-DD";and see if it will be accepted. Add a conclusion from all the discussions here.My main concern here is about the
parseDrvNameissue. The way they are written now,versioncan't includeunstableon it.
That is Eelco’s concern as well and he is very adamant about it.
I would like it. What can I do?
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.
7c6f434c
commented
3 years ago 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-envwill consider them two different packages and will not update even with--always(which should IMO 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+$commitHashwhich would solve theparseDrvNameissue and upgrades between stable and temporarily unstable versions – but not upgrades between unstable versions without--alwayssince commit hashes are not monotonous.
$lastStableVersion-unstable-$date-$hash would be so nice to have agreed…
AndersonTorres
commented
3 years ago @7c6f434c
$lastStableVersion-unstable-$date-$hash would be so nice to have agreed…
No, no, no. ${last-stable-version}-unstable-${date in yyyy-mm-dd format} should be good enough.
And, for the sake of unambiguity, a project without clearcut releases should have a default last-stable-version := 0.0.0.
Hashes are low-level info. For us non-machines, dates are way more useful than a cryptical soup of letters generated by a machine.
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?
@jtojnar
The first step would probably be formulating why are the current rules not good enough.
I would say ambiguity is the issue here. Many possibilities and no uniformity.
Then we can compile list of alternatives and compare them against the criteria.
My current stance is ${last-stable-version}-unstable-${date in yyyy-mm-dd format}. I think it is a good compromise between not changing parseDrvName and keeping useful info about version.
Arch did something like $lastStableVersion-git+$commitHash
IIANW, it is mostly from AUR. Anyway I think the model above captures the intent well enough.
7c6f434c
commented
3 years ago For us non-machines, dates are way more useful than a cryptical soup of letters generated by a machine.
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
nixos-discourse
commented
3 years ago 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
figsoda
commented
2 years ago I like the idea of 0.0.0-unstable.2021-09-23 or 0.0.0-git.2021-09-23, which follows semantic versioning
AndersonTorres
commented
2 years ago I will upload a RFC shortly.
AndersonTorres
commented
2 years ago As promised:
stale[bot]
commented
2 years ago I marked this as stale due to inactivity. → More info
rhendric
commented
1 year ago Is #234201 merging enough to close this issue?
jtojnar
commented
1 year ago The issue will persist until the packages switch to the new convention.
jtojnar
commented
1 year ago And probably also support code like https://github.com/NixOS/nixpkgs/blob/3a1e7765172c444c348dde552ab4fa549ef59b27/pkgs/common-updater/unstable-updater.nix.
As discussed in https://github.com/repology/repology/issues/854#issuecomment-530450656, 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