[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [EXTERNAL]Re: Modifying squashfs usage for `guix pack` for supportin
From: |
Ludovic Courtès |
Subject: |
Re: [EXTERNAL]Re: Modifying squashfs usage for `guix pack` for supporting singularity |
Date: |
Fri, 13 Mar 2020 17:38:51 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
Hi Josh,
Josh Marshall <address@hidden> skribis:
> While the images seem to work well in most cases, removing ways for bits to
> change seems to be in the spirit of guix, and so the "-all-time" and
> "-mkfs-time" options remove one source of change. Additionally, without the
> "--no-recovery" an extra file is made which is not useful to the process, and
> for my manual testing seemed to cause write or permission issues which could
> cause failures. Guix already handles the failure cases in mksquashfs which
> the recovery file is for and so the redundant work is not helpful, can cause
> problems, slows down the process, and requires more resources.
Oh, I hadn’t understood that there were reproducibility issues with
‘guix pack -f squashfs’, sorry about that!
Commits 24fb0dc0ab34ebb49509a3d5b4d84d8488670807 and
b829864d747b3b24ef37cafe36e889527b060d4d implement what you suggest.
I can confirm that now something like:
guix pack -f squashfs sed --rounds=2
passes, which was not the case before.
Thanks!
> As for the information given by `guix pack --list-formats`, I'd change to
> something like the following:
>
> ```
> tarball Self-contained tarball, ready to run directly on any Linux
> machine
> squashfs Container suitable for Singularity 2.x and 3.x
> OCI OCI compliant tarball ready for 'docker load' and usable by
> Singularity 3.x
> sif Unsupported; container preferred by Singularity 3.x
We cannot change the format name, for compatibility reasons, but I’ll
double-check that what ‘-f docker’ produces is indeed OCI, and if so,
add it to the description.
> For more information, refer to
> https://guix.gnu.org/manual/en/html_node/Invoking-guix-pack.html
I don’t think we’re going to add references to the manual in --help and
similar: it’s always implicit that documentation is in the manual.
However, perhaps we could add terminal hyperlinks to make it more
discoverable.
Thanks,
Ludo’.