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

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

[Ben Woodcroft]

Hi,

I have a profile with python@2 in it, and running 'guix package -u' 
updates it to python@3, which isn't what I want. I cannot run 'guix 
package -i python@2 -u' because then it tries to install both python@2 
and python@3, which conflicts.

I can workaround this using 'guix package -u; guix package -i python@2'. 
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.

Ideally, I would expect that because I specified python@2 first, guix 
should not try to install python@3. However, this difficult because IIUC 
the packages which were specified to be included are not stored 
anywhere, and I suppose it would entail changes to the manifest format 
also. So, how to handle this?

Thanks, ben

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

[Alex Kost]

Ben Woodcroft (2017-10-07 16:14 +1000) wrote:

> Hi,

Hello,

> I have a profile with python@2 in it, and running 'guix package -u'
> updates it to python@3, which isn't what I want. I cannot run 'guix
> package -i python@2 -u' because then it tries to install both python@2
> and python@3, which conflicts.
>
> I can workaround this using 'guix package -u; guix package -i
> python@2'. 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.
>
> Ideally, I would expect that because I specified python@2 first, guix
> should not try to install python@3. However, this difficult because IIUC
> the packages which were specified to be included are not stored
> anywhere, and I suppose it would entail changes to the manifest format
> also. So, how to handle this?

Not sure if you find the following workaround useful, but you may just
make your own python package and install it instead:

(define-public my-python-2
  (package
    (inherit python-2)
    (name "python2")))

Since this "python2" has only version 2, it will never be upgraded to
version 3.  I mean there will be "python2@2" but not "python2@3", so if
you install it ("guix package -i python2"), "guix package -u" will
update it to the current version of the python-2 series.

-- 
Alex

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

[Ludovic Courtès]

Hello,

Ben Woodcroft <b.woodcroft@uq.edu.au> skribis:

> I have a profile with python@2 in it, and running 'guix package -u'
> updates it to python@3, which isn't what I want. I cannot run 'guix
> package -i python@2 -u' because then it tries to install both python@2
> and python@3, which conflicts.
>
> I can workaround this using 'guix package -u; guix package -i
> python@2'. 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 python@2

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’.

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

[Ludovic Courtès]

Hi,

ludo@gnu.org (Ludovic Courtès) skribis:

> There’s this possibility:
>
>   guix package -u . -r python -i python@2
>
> I admit it’s a bit contrived though.
>
> There are several ways to address it:
>
>   1. Rename our Python 2.x package “python2”.

That was done long ago, so I’m closing this bug.

Ludo’.