I believe there's the .24 because of the patch? I do notice exherbo has p24 which I guess means patch 24. It probably should be in the version string to signify that it's in fact different than 0.34 because of the patch.

I believe there's the .24 because of the patch?

yes, it's the version of the debian patch. debian itself still uses the upstream version "0.3"

I do notice exherbo has p24 which I guess means patch 24.

yes, i think that's the case

It probably should be in the version string to signify that it's in fact different

maybe, maybe not. it should at least be consistent. i think we don't have a policy for that currently.

but at the same time we have many distro specific patches and still use the official release versions. so i proposed to do it here also...

Do you know a good version scheme to have additional external patches included?

"0.3.24" would be very bad. it implies that its an official version number. and what if that official version get's released?

What if there are multiple patches? bash for example has 23 patches! https://github.com/NixOS/nixpkgs/blob/92a047a6c4d46a222e9c323ea85882d0a7a13af8/pkgs/shells/bash/bash-4.4-patches.nix

I believe there's the .24 because of the patch?

yes, it's the version of the debian patch. debian itself still uses the upstream version "0.3"

I do notice exherbo has p24 which I guess means patch 24.

yes, i think that's the case

It probably should be in the version string to signify that it's in fact different

maybe, maybe not. it should at least be consistent. i think we don't have a policy for that currently.

but at the same time we have many distro specific patches and still use the official release versions. so i proposed to do it here also...

Do you know a good version scheme to have additional external patches included?

"0.3.24" would be very bad. it implies that its an official version number. and what if that official version get's released?

What if there are multiple patches? bash for example has 23 patches! https://github.com/NixOS/nixpkgs/blob/92a047a6c4d46a222e9c323ea85882d0a7a13af8/pkgs/shells/bash/bash-4.4-patches.nix

Well with the case with debian, it's probably a good idea to believe 0.3 != 0.3 because debian is pretty much downstream patches all the way down 😄

But right, 0.3.24 is not good at all. Not sure why it's like that in debian, I think they'd do something like 0.3-debian_revision

• https://www.debian.org/doc/debian-policy/ch-controlfields.html#version

Perhaps repology stripped that info.

Not sure why it's like that in debian, I think they'd do something like 0.3-debian_revision
Perhaps repology stripped that info.

you are right!

https://packages.debian.org/unstable/source/xzoom

xzoom (0.3-25)

I'm not sure if we need to show if our packages have patches or not. Patches should in best case fix issues and provide the behavior upstream intended. If something is broken with out package, users will create an issue here. We will not add new features with patches! But sometimes fix security issues where upstream has not released a new version yet.

We have to discuss it somewhere. What would be a good place? nixpkgs issue, nix issue, discourse, RFC?

The discussion in #73228 leads to the conclusion that it don't really makes sense to add patch version to package version.