unexpected download after gc

  • Open
  • quality assurance status badge
Details
3 participants
  • David Elsing
  • raingloom
  • zimoun
Owner
unassigned
Submitted by
zimoun
Severity
normal
Z
Z
zimoun wrote on 18 Mar 2022 14:50
(address . bug-guix@gnu.org)
877d8r8j5i.fsf@gmail.com
Hi,

Considering this with revision a03936a:

guix gc
guix install python-ipython -p tools
guix gc
guix install python-ipython -p tools

I am surprised that:

1. the second GC collects things
2. the second install downloads things

especially by this line:

python-ipython-7.27.0 892KiB 4.6MiB/s 00:00 [##################] 100.0%


Well, it is because of grafts. The profile contains the grafted
version and the installation expect first the non-grafted for computing
the graft. For instance:

Toggle snippet (9 lines)
$ guix gc --list-dead | grep ipython
finding garbage collector roots...
determining live/dead paths...
/gnu/store/xmw4vxabnkm7vwa0ywfcqcmknbnia0c3-python-ipython-7.27.0

guix build python-ipython --no-grafts
/gnu/store/xmw4vxabnkm7vwa0ywfcqcmknbnia0c3-python-ipython-7.27.0

When something is grafted, is it possible to consider the non-grafted as
a "derivation", i.e., control the GC with 'gc-keep-derivations'.

Or the grafted could keep a reference to the non-grafted?


Well, I was expecting that this composition:

guix gc && guix install

was "idempotent" in a way. :-) And to me, the fact that it is not is
somehow a bug. Maybe, it is already well-known and not considered as
bug.


Cheers,
simon
R
R
raingloom wrote on 22 Mar 2022 21:00
(address . bug-guix@gnu.org)
20220322210028.23cfe132@riseup.net
On Fri, 18 Mar 2022 14:50:01 +0100
zimoun <zimon.toutoune@gmail.com> wrote:

Toggle quote (55 lines)
> Hi,
>
> Considering this with revision a03936a:
>
> guix gc
> guix install python-ipython -p tools
> guix gc
> guix install python-ipython -p tools
>
> I am surprised that:
>
> 1. the second GC collects things
> 2. the second install downloads things
>
> especially by this line:
>
> python-ipython-7.27.0 892KiB 4.6MiB/s 00:00 [##################]
> 100.0%
>
>
> Well, it is because of grafts. The profile contains the grafted
> version and the installation expect first the non-grafted for
> computing the graft. For instance:
>
> --8<---------------cut here---------------start------------->8---
> $ guix gc --list-dead | grep ipython
> finding garbage collector roots...
> determining live/dead paths...
> /gnu/store/xmw4vxabnkm7vwa0ywfcqcmknbnia0c3-python-ipython-7.27.0
>
> guix build python-ipython --no-grafts
> /gnu/store/xmw4vxabnkm7vwa0ywfcqcmknbnia0c3-python-ipython-7.27.0
> --8<---------------cut here---------------end--------------->8---
>
> When something is grafted, is it possible to consider the non-grafted
> as a "derivation", i.e., control the GC with 'gc-keep-derivations'.
>
> Or the grafted could keep a reference to the non-grafted?
>
>
> Well, I was expecting that this composition:
>
> guix gc && guix install
>
> was "idempotent" in a way. :-) And to me, the fact that it is not is
> somehow a bug. Maybe, it is already well-known and not considered as
> bug.
>
>
> Cheers,
> simon
>
>
>

There should definitely be more attention paid to offline use so IMHO
this is a bug. Or at least missing feature.
D
D
David Elsing wrote on 29 Oct 2023 20:36
Re: unexpected download after gc
(address . zimon.toutoune@gmail.com)(address . 54495@debbugs.gnu.org)
86pm0xgqzr.fsf@posteo.net
Hello,

AFAICT, there is no way to determine which ungrafted package a grafted
package comes from without the derivation of the grafted package (where
the ungrafted package is referenced). Therefore, I think adding a
reference to the ungrafted package in the package itself (your second
suggestion) would be the simplest way: https://issues.guix.gnu.org/66824

Presently, it is inconvenient to globally run guix gc at all for me, as
many (dependent) packages are deleted and substituted again when
rebuilding several profiles built with grafts.

Cheers,
David
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 54495@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 54495
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch