bug#28727: Profiles with intentionally out of date packages are upgraded to the newest version

[Ludovic Courtès]

Hello,

Ben Woodcroft <address@hidden> skribis:

> I have a profile with address@hidden in it, and running 'guix package -u'
> updates it to address@hidden, which isn't what I want. I cannot run 'guix
> package -i address@hidden -u' because then it tries to install both 
> address@hidden
> and address@hidden, which conflicts.
>
> I can workaround this using 'guix package -u; guix package -i
> address@hidden'. That isn't ideal (wasteful downloading of substitute, extra
> entries in the generations list, etc), but is workable for me, making
> this a low priority bug for me.

There’s this possibility:

  guix package -u . -r python -i address@hidden

I admit it’s a bit contrived though.

There are several ways to address it:

  1. Rename our Python 2.x package “python2”.

  2. Add a property to the ‘python’ package that describes it as part of
     the “2.” series, and have the upgrade mechanism honor that property
     by upgrading to a version prefixed with “2.”.

#1 is obviously easier (it triggers a lot of rebuild though).

Thoughts?

Ludo’.