GNU bug report logs -
#71360
large manifests when adding packages
Previous Next
To reply to this bug, email your comments to 71360 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#71360
; Package
guix
.
(Tue, 04 Jun 2024 11:39:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Dariqq <dariqq <at> posteo.net>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Tue, 04 Jun 2024 11:39:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#71360
; Package
guix
.
(Tue, 04 Jun 2024 17:45:03 GMT)
Full text and
rfc822 format available.
Message #8 received at 71360 <at> debbugs.gnu.org (full text, mbox):
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:
> 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.
This bug report was last modified 95 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.