help-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Two copies of same library in store after cleaning generations and g


From: Mike Jones
Subject: Re: Two copies of same library in store after cleaning generations and gc
Date: Fri, 19 Aug 2022 12:37:18 +0100
User-agent: Cyrus-JMAP/3.7.0-alpha0-841-g7899e99a45-fm-20220811.002-g7899e99a

Hi all!

On Fri, 19 Aug 2022, at 7:13 AM, Ricardo Wurmus wrote:
> This sounds like grafts working as intended.  Do you also have more
> than one instance of icecat – one using the graft and one without?

After building the profile do I indeed have two instances of icecat in
the store. But when I run `guix gc`, the ungrafted one is of course
deleted, and I'm left with a single instance.

With mesa, however, there are always two active instances of mesa (also
some other libraries, e.g. gtk) referenced by the profile. I expected
that there would only be one (grafted) instance.

On Fri, 19 Aug 2022, at 10:06 AM, zimoun wrote:
> Well, all seems consistent, isn’t it?  I hope now it is less
> confusing.

Yeah, thanks for working through this - I understand better now :) So we
have one original ungrafted output, which is:

  /gnu/store/wdm2s2si8fqsrcd5xpc29ivmpkf20s8d-mesa-21.3.8

This then gets separately grafted twice to produce two new outputs:

  /gnu/store/74ags388lb0xasf7v1h8j9ywj8zrsgv9-mesa-21.3.8 (result of `guix 
build mesa`)
  /gnu/store/lcqz4q3834bjd3dlc8zsr95mvzz9n006-mesa-21.3.8 (referred to by 
icecat)

But I wonder why icecat refers to a different mesa to `guix build
mesa`.

Running

  $ diffoscope /gnu/store/lcqz4q3834bjd3dlc8zsr95mvzz9n006-mesa-21.3.8 \
  /gnu/store/74ags388lb0xasf7v1h8j9ywj8zrsgv9-mesa-21.3.8`

(takes quite a long time to run!) shows me that many of the files are
different, but only in self-references.

I also diffed the guile-builder scripts for the two grafted mesa
instances. Here's the first difference:

  -    (map (lambda (o) (cons o (getenv o)))
  -         '("bin" "out")))
  +    (map (lambda (o) (cons o (getenv o))) '("out")))

It seems that one is a graft of just the default output, while the other
also includes the "bin" output! I think this explains why there are two
separate grafts, that produce the same (minus self-references) output.

Presumably these aren't deduplicated due to the differing
self-references?

- Mike



reply via email to

[Prev in Thread] Current Thread [Next in Thread]