guix package conflict

guix package conflict

[Andy Tai]

Hi, on my Fedora system running guix as guix on a foreign distribution, I
run into this:

guix package: error: profile contains conflicting entries for cairo
guix package: error:   first entry: cairo@1.16.0
/gnu/store/4d8rc6vjkhsk1b20rigz0nzl7zffn4b5-cairo-1.16.0
guix package: error:    ... propagated from python-pycairo@1.17.1
guix package: error:   second entry: cairo@1.16.0
/gnu/store/cwqv36m84ipbpwn52wyy560xbxrzknsz-cairo-1.16.0
guix package: error:    ... propagated from pango@1.42.4
guix package: error:    ... propagated from gtk+@3.24.9
hint: Try upgrading both `python-pycairo' and `gtk+', or remove one of them
from
the profile.


I regularly do

guix pull && guix package -u

so I cannot recall how I got into this situation.   I have packages
depending on both gtk+ and
python-pycairo' so it seems I cannot just remove either one of them.  What
would be the best approach to fix this?
-- 
Andy Tai, atai@atai.org, Skype: licheng.tai, Line: andy_tai, WeChat:
andytai1010
Year 2019 民國108年
自動的精神力是信仰與覺悟
自動的行為力是勞動與技能

Re: guix package conflict

[Ricardo Wurmus]

Hi Andy,

> guix package: error: profile contains conflicting entries for cairo
> guix package: error:   first entry: cairo@1.16.0
> /gnu/store/4d8rc6vjkhsk1b20rigz0nzl7zffn4b5-cairo-1.16.0
> guix package: error:    ... propagated from python-pycairo@1.17.1
> guix package: error:   second entry: cairo@1.16.0
> /gnu/store/cwqv36m84ipbpwn52wyy560xbxrzknsz-cairo-1.16.0
> guix package: error:    ... propagated from pango@1.42.4
> guix package: error:    ... propagated from gtk+@3.24.9
> hint: Try upgrading both `python-pycairo' and `gtk+', or remove one of them
> from
> the profile.

Have you tried that?

> I regularly do
>
> guix pull && guix package -u
>
> so I cannot recall how I got into this situation.   I have packages
> depending on both gtk+ and
> python-pycairo' so it seems I cannot just remove either one of them.  What
> would be the best approach to fix this?

Does “guix package -u” not fix this problem for you?  Or is this the
output of “guix package -u”?

-- 
Ricardo

Re: guix package conflict

[Carlo Zancanaro]

On Sat, Aug 10 2019, Ricardo Wurmus wrote:
>> hint: Try upgrading both `python-pycairo' and `gtk+', or remove 
>> one of them from the profile.
>
> Have you tried that?

In particular, I think `guix package -i python-pycairo gtk+` might 
do the trick.

> Does “guix package -u” not fix this problem for you?  Or is this 
> the output of “guix package -u”?

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

Carlo

Re: guix package conflict

[Andy Tai]

This command solved the problem.

guix package -i gtk+ python-pycairo python2-pycairo  pango cairo fontconfig

Thanks

On Sat, Aug 10, 2019 at 2:58 AM Carlo Zancanaro <carlo@zancanaro.id.au>
wrote:

>
> On Sat, Aug 10 2019, Ricardo Wurmus wrote:
> >> hint: Try upgrading both `python-pycairo' and `gtk+', or remove
> >> one of them from the profile.
> >
> > Have you tried that?
>
> In particular, I think `guix package -i python-pycairo gtk+` might
> do the trick.
>
> > Does “guix package -u” not fix this problem for you?  Or is this
> > the output of “guix package -u”?
>
> 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). 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.
>
> Carlo
>


-- 
Andy Tai, atai@atai.org, Skype: licheng.tai, Line: andy_tai, WeChat:
andytai1010
Year 2019 民國108年
自動的精神力是信仰與覺悟
自動的行為力是勞動與技能

Re: guix package conflict

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 860 bytes --]

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). 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?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: guix package conflict

[Mark H Weaver]

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

Re: guix package conflict

[Carlo Zancanaro]

Hey Mark,

On Mon, Aug 12 2019, Mark H Weaver wrote:
> What leads you to believe this?
>
> I think you're mistaken, based both on past experience and also 
> from examining the current code.

After taking another look at the code, I agree with you.

> 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

This is the code I was looking at, but I think I was just too 
hasty when I looked at it. In the past I've seen conflicts similar 
to what Andy saw, and was always able to resolve them easily by 
using "guix package -i" rather than "guix package -u", from which 
I formed my hypothesis about how --upgrade deals with versions.

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

I have also switched to using --manifest, so my memories of 
--upgrade aren't very strong.

Carlo