large manifests when adding packages

  • Open
  • quality assurance status badge
Details
One participant
  • Dariqq
Owner
unassigned
Submitted by
Dariqq
Severity
normal
D
D
Dariqq wrote on 4 Jun 13:38 +0200
(address . bug-guix@gnu.org)
253771a3-f41d-4888-9fa1-0b4ac761c59e@posteo.net
Hi Guix,

I was trying to figure out if the "repeated" tag inside a profiles
manifest file is reliable to detect duplicate entries in a profile.
While it was working fine for my home and system profile for the normal
.guix-profile it was not:

This is related to https://issues.guix.gnu.org/55499#0resp.
which marks duplicate entries in a profiles as repeated inside the
profile manifest file.

* Steps to reproduce

To stick with the original example: Instead of adding the r packages all
in one add them one by one

#+begin_example
guix package -p /tmp/wrong -i r-cicero-monocle3
guix package -p /tmp/wrong -i r-monocle3
#+end_example

The resulting manifest file at /tmp/wrong/manifest has the huge tree for
r-monocle3 twice.

So the lookup mechanism in manifest->gexp does not seem to work with the
install mechanism of profiles. I haven't looked more deeply into it yet.

An smaller example is using zlib and glib (which propagates zlib).

* Expected Behaviour

It should not matter whether you install things in multiple transactions
or in one.

Thanks.
D
D
Dariqq wrote on 4 Jun 19:35 +0200
(address . 71360@debbugs.gnu.org)
946c8da8-e70f-4c9a-b4e0-1c070be15ac1@posteo.net
I think (maybe part of) the problem is that inside entry->gexp in
manifest->gexp things get compared using (the hash of)
(manifest-entry-item entry) which will be a package object for the new
entries but a store path "/gnu/store/*" for packages already present in
the profile.

Also right afterwards we test if the visited previous-entry is
'manifest-entry=?' to entry again causing a potential problem if one has
a string and one a package as item entry.

Would this be worth fixing?


On 04.06.24 13:38, Dariqq wrote:
Toggle quote (34 lines)
> Hi Guix,
>
> I was trying to figure out if the "repeated" tag inside a profiles
> manifest file is reliable to detect duplicate entries in a profile.
> While it was working fine for my home and system profile for the normal
> .guix-profile it was not:
>
> This is related to https://issues.guix.gnu.org/55499#0 resp.
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=4ff12d1de7cd617b791996ee7ca1240660b4c20e which marks duplicate entries in a profiles as repeated inside the profile manifest file.
>
> * Steps to reproduce
>
> To stick with the original example: Instead of adding the r packages all
> in one add them one by one
>
> #+begin_example
> guix package -p /tmp/wrong -i r-cicero-monocle3
> guix package -p /tmp/wrong -i r-monocle3
> #+end_example
>
> The resulting manifest file at /tmp/wrong/manifest has the huge tree for
> r-monocle3 twice.
>
> So the lookup mechanism in manifest->gexp does not seem to work with the
> install mechanism of profiles. I haven't looked more deeply into it yet.
>
> An smaller example is using zlib and glib (which propagates zlib).
>
> * Expected Behaviour
>
> It should not matter whether you install things in multiple transactions
> or in one.
>
> Thanks.
?
Your comment

Commenting via the web interface is currently disabled.

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

To respond to this issue using the mumi CLI, first switch to it
mumi current 71360
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