Re: guix package conflict

[Mark H Weaver <mhw@netris.org>]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Carlo Zancanaro <carlo@zancanaro.id.au> writes:
>
>> It looks like `guix package -u` compares the version of the 
>> package, and only updates if the package's version has changed 
>> (and even then, only if it has increased).

What leads you to believe this?

I think you're mistaken, based both on past experience and also from
examining the current code.  The relevant procedure is
'transaction-upgrade-entry' in (guix scripts package), here:

  https://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/package.scm?id=c383c36edeb7eb358f142c52276d6e5d32bda044#n225

You can see there where 'version-compare' is used to compare the
candidate version and the existing version.  If the version numbers are
equal, then the derivation output paths are compared.  If the output
paths differ, the new version will be reinstalled.

This is certainly the behavior I remember from using --upgrade myself
during the early years of Guix, although in recent years I've been
using the declarative approach to maintain my profile, using
"guix package --manifest".

>> This means that if a 
>> package's inputs (and thus its store hash) have changed, but its 
>> version has not, the version left in the profile will have 
>> outdated inputs, which can conflict if they are propagated. So 
>> `guix package -u` doesn't fix this problem.
>>
>> `guix package -i`, on the other hand, just installs whatever it's 
>> told to, so it will install the same package at the same version, 
>> but with updated inputs. Then all the propagated inputs end up 
>> being the same, so there is no conflict.
>
> I didn't know that! O.o
> Is this documented in the manual?

I hope not.  If it truly behaves the way Carlo described, it's a bug.

     Thanks,
       Mark