[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Finding the store path of a package
From: |
Konrad Hinsen |
Subject: |
Re: Finding the store path of a package |
Date: |
Mon, 19 Apr 2021 09:08:54 +0200 |
Hi Ludo,
> Why #:graft? #f? Because if you enable graft, you’ll potentially have
> to build/download the thing, and that wouldn’t buy you anything because
> the set of file names is the same in the grafted package.
Four weeks later: this mostly works, but sometimes fails (by
downloading/building package) and it rarely fails completely
(error message). And I have no idea what is going on.
As an experiment, I ran the attached script via "guix repl". It requests
and displays the store paths for all non-hidden packages. Using
"guix gc" before and after, I found that it downloads/builds
more than 50000 store entries with a total size of 7.5 GB.
One small but interesting example: ABCL
##################################################
Store paths for abcl@1.8.0:
fetching path `/gnu/store/rz42ba0my9vrgbkjpkzr2drmnjk5ah50-python-3.8.2'...
Downloading
https://ci.guix.gnu.org/nar/lzip/rz42ba0my9vrgbkjpkzr2drmnjk5ah50-python-3.8.2...
python-3.8.2 12.0MiB 1.8MiB/s 00:07 [##################] 100.0%
fetching path
`/gnu/store/bvd09gb8ka642jzgxd2lpqlpdp160gn0-python-wrapper-3.8.2'...
Downloading
https://ci.guix.gnu.org/nar/lzip/bvd09gb8ka642jzgxd2lpqlpdp160gn0-python-wrapper-3.8.2...
python-wrapper-3.8.2 347B 177KiB/s 00:00 [##################] 100.0%
fetching path `/gnu/store/h8z924ip7ialjhd3sc2id5yh0jy7cj20-python-nose-1.3.7'...
Downloading
https://ci.guix.gnu.org/nar/lzip/h8z924ip7ialjhd3sc2id5yh0jy7cj20-python-nose-1.3.7...
python-nose-1.3.7 197KiB 1.4MiB/s 00:00 [##################] 100.0%
fetching path `/gnu/store/cshy0265w5ifh12v9dcmlrdd3cwb61db-mercurial-5.6.1'...
Downloading
https://ci.guix.gnu.org/nar/lzip/cshy0265w5ifh12v9dcmlrdd3cwb61db-mercurial-5.6.1...
mercurial-5.6.1 3.3MiB 3.1MiB/s 00:01 [##################] 100.0%
((out . "/gnu/store/nz8xi3x7n3v2k4s4piiw7r8plvxam9qz-abcl-1.8.0"))
##################################################
Why does computing the store path for a Java package require fetching
Mercurial (and thus Python)? The only link I see is icedtea-6, whose
build procedure apparently uses Mercurial to download the OpenJDK
sources. Probably this gets inherited by icedtea-8, which is used for
building ABCL. But... why does it take Mercurial to just compute the
store path??? If my understanding of Guix hashes is correct (which I am
beginning to doubt), it shouldn't require more than the hash of the
Mercurial package.
As an example for a hard failure, see sunxi-tools@1.4.2. Asking for
its store paths downloads plenty of stuff, before failing with:
while setting up the build environment: a `armhf-linux' is required to build
`/gnu/store/4blcfrrzc3yx6xjvw31mhnr1r9lpw4mj-Python-3.8.2.tar.xz.drv', but I am
a `x86_64-linux'
That makes sense, of course, and I don't mind getting an error in such a
case, but I'd prefer it to fail without first downloading tons of stuff,
including the heavyweight gcc-7.5.0.
Cheers,
Konrad.
display-store-paths.scm
Description: Binary data
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Finding the store path of a package,
Konrad Hinsen <=