nixpkgs-update icon indicating copy to clipboard operation
nixpkgs-update copied to clipboard

Don't update packages pinned to specific version

Open dotlambda opened this issue 8 years ago • 9 comments

In https://github.com/NixOS/nixpkgs/pull/37474, you tried to update libgit2_0_25 to version 0.26.3, which doesn't make sense.

dotlambda avatar Mar 20 '18 18:03 dotlambda

There are lot of different version formats in attr paths. Here's a list of ones I know about:

attrpath format example version represented
name(MAJORDIGIT)(MINORDIGIT) qt56 5.6.x
name(major) icu58 58.x
name(majordigit)(minor) autoconf213 2.13
name(majordigit)(minor)x automake111x 1.11.x
name(digit_not_in_version)(major)(minor) libgit2_0_25 0.25.x
name-(major)-(minor)-(patch) libsigrok-0-3-0 0.3.0
name_(major)_(minor) apacheKafka_0_10 0.10.x
name-(major)_(minor) dbus-sharp-glib-2_0 2.0.x
name(major)_(minor) antlr3_5 3.5.x
name(major) bison3 3.x.x
name(digit_not_in_version) automoc4 x.x.x
name_(date) fplll_20160331 20160331
name owncloud-client x.x.x
name(unrelatednumbers) libavc1394 x.x.x

ryantm avatar Mar 23 '18 04:03 ryantm

Maybe nixpkgs should have a policy for this.

jtojnar avatar Apr 08 '18 15:04 jtojnar

There is a policy for naming the files, but not the attr paths.

ryantm avatar Apr 08 '18 15:04 ryantm

https://discourse.nixos.org/t/an-attrpath-format-policy-proposal/235

ryantm avatar May 19 '18 22:05 ryantm

https://github.com/NixOS/nixpkgs/issues/17625

ryantm avatar May 21 '18 21:05 ryantm

On the mailing list I proposed a meta attribute for this "Proposal new meta attribute: meta.permitAutoUpgrade".

For the Python package set I would like to introduce a new meta attribute to indicate to update scripts whether the package may be upgraded to a newer version. The motivation is that I want to exclude some packages from my update script. While I am only interest in Python packages, I think it is good to consider the whole of Nixpkgs before introducing attributes like these.

I propose an attribute meta.permitAutoUpgade which takes either a boolean, or one of "major", "minor", "patch". When set to true, the package may be upgraded to any version, and when set to false tools should not update the expression. When "major" is set major version upgrades may be performed; this is effectively the same as passing true. With "minor" only minor upgrades and "patch" only patch-level updates.

FRidh avatar Jul 22 '18 06:07 FRidh

@FRidh what are some usecases you envision to have this level of granularity, as opposed to just a boolean? Is it related to, e.g. a package having two major versions for different Python versions?

Also, what would be the ideal default? I'm thinking true globally, and possibly override that for e.g. all of Python if that turns out to be necessary.

asymmetric avatar Feb 19 '19 10:02 asymmetric

@asymmetric typicallly it is perfectly fine to update patch level changes, but with minor and major that's not always the case. Default is indeed true or "major".

In case of Python I want to limit auto-upgrading of certain packages when I know it cannot result in a coherent package set.

FRidh avatar Feb 19 '19 10:02 FRidh

Also, with Python it becomes increasingly important now that many packages no longer release Python 2 compatible versions. Then we need to restrict certain expressions.

FRidh avatar Feb 19 '19 10:02 FRidh