Show that we have patches in version?

[davidak]

In #72178 came the question up how we want to show patches in package versions.

Right now i think we have just the version of the upstream release and it is not visible that we change it with patches.

That might be OK since we don't change the behavior of the package (e.g. adding features) and only fixing security problems or make it usable with Nix in the first place.

debian has the version format upstream_version[-debian_revision]. We could adopt that and increment the number every time our patches change. But i actually see no value.

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

@AMDmi3 do you have a suggestion how to represent distro-specific patches in a version number? Is there a common practice distros use?

cc @worldofpeace

Related:

• Semantically tag CVE patches #15660
• [RFC] Structured patches #39392

[AMDmi3]

@AMDmi3 do you have a suggestion how to represent distro-specific patches in a version number? Is there a common practice distros use?

First of all, there are 2 distinct issues here, and I'm not sure which one you're primarily talking about.

The first one is conveying package updates where upstream version doesn't change (and that include adding patches). This is done by almost all repositories in some form of package revision, e.g. basically an additional version component (visibly and unambiguously separated from upstream version though). For example, in FreeBSD it would be 1.2.3 → 1.2.3_1 → 1.2.3_2 etc. Repology effectively strips these. And for Debian it's in fact much more complex than just a simple number, and they may append huge and complex suffixes.

If nix wants to implement these, the best would be to implement it as a separate field (e.g. {"version": "1.2.3", "revision": 2}, so there's no need to split it from the version. If it has to be part of the version, any suffix would do as long as it can be stripped reliably, e.g. a separator should be used which may never be encountered in the upstream version part.

Another issue is packaging a software repackaged by another distro - Debian in this case, and in fact I haven't encountered any cases with other distros as only Debian always repackages the sources, and thus sometimes becomes the new upstream if the original upstream is gone or inactive for decades. In this case, whole Debian version has to be imported (as "upstream version"), including the Debian revision (or larger suffix), and Repology cannot strip this that easily. For now, this is solved by specific kind of rules not unexpectedly called "debianism". These currently work the same ways as "devel" rules, e.g. effectively allow a newer version (e.g. with Debian suffix) to exist without making an older one (original upstream which most distros prefer) outdated.

If nix wants to improve support for these, I'd suggest making it more apparent that the suffix comes from Debian (e.g. 0.3.24 → 0.3.debian.24). This way both the users would know that the package comes from Debian instead of original upstream, and Repology would be able to handle these suffixes automatically. In future, it may be possible to do handle version comparison for there as a special case, e.g. it would be possible to compare versions known to come from debian with complete debian versions (as opposed to stripped ones as it's done now).

[jtojnar]

I would say that in classic package managers, the revisions are there to distinguish when the package changed for other reason than upstream update (for example, metadata changes, or ABI change in one of the dependencies libraries) and requires package to be re-build.

Nix can distinguish if a package changes based on the hash of the derivation generated by the expression, so it does not need such extra attribute.

[davidak]

@jtojnar sure, when packages are configured declaratively, the version present in the current nixpkgs channel is used. but what about imperative package updates? do we need a higher version, so the package get's updated or could it have basically the same version and still update, e.g. when a patch was added?

[symphorien]

nix-env has the flag --leq for such cases.

[vcunat]

Unless you want to differentiate from the case when some dependencies get updated without changing the package itself, but I can't think of a reason to do that. Note that adding patches isn't the only change that can happen in the expression, and even if package hasn't changed at all, some dependency (library) might have fixed security issues and thus you do want to "upgrade" that closure. So far I can't really see any motivation to reflect any of this in package version or a similar field.

BTW, I prefer to use --always instead of --leq. If "community" decided that downgrade is the best way, I don't see why override that decision by default.

[davidak]

OK, thanks all.

Do we want to document that in the version section?

[davidak]

A good place seems 18.6. Patches.

I propose the text:

The version of the package should not be changed if patches have been applied. Nix can distinguish if a package changes based on the hash of the derivation generated by the expression.

Is that proper english? (I'm not a native speaker)

I would add it at the end of the section as a hint, if that is possible to markup.

[stale]

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:

1. Search for maintainers and people that previously touched the
   related code and @ mention them in a comment.
2. Ask on the NixOS Discourse. 3. Ask on the #nixos channel on
   irc.freenode.net.

[davidak]

i will document it... (soon)

[stale]

I marked this as stale due to inactivity. → More info

[davidak]

Waiting for doc to become Markdown.

[stale]

I marked this as stale due to inactivity. → More info

[soupglasses]

Update on this being documented?