-
-
Notifications
You must be signed in to change notification settings - Fork 14k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Show that we have patches in version? #73228
Comments
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 If nix wants to implement these, the best would be to implement it as a separate field (e.g. 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. |
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. |
@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? |
nix-env has the flag |
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 |
OK, thanks all. Do we want to document that in the version section? |
A good place seems 18.6. Patches. I propose the text:
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. |
Thank you for your contributions.
|
i will document it... (soon) |
I marked this as stale due to inactivity. → More info |
Waiting for doc to become Markdown. |
I marked this as stale due to inactivity. → More info |
Update on this being documented? |
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:
The text was updated successfully, but these errors were encountered: