From: Mathieu Othacehe <m.othacehe@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 40955@debbugs.gnu.org
Subject: [bug#40955] [PATCH 4/5] image: Add a new API.
Date: Tue, 05 May 2020 15:52:30 +0200 [thread overview]
Message-ID: <87pnbicwv5.fsf@gmail.com> (raw)
In-Reply-To: <87wo5u8prf.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sat, 02 May 2020 14:50:28 +0200")
> Would it make sense to separate #:owner-uid and #:owner-gid?
Yes, fixed.
>
> It does mean that we can only create images where all the files have the
> same UID/GID.
>
> Looking at (gnu build install), there’s one case where it might be
> problematic: the store’s GID is supposed to match the ‘guixbuilder’
> group. But the good news is that the daemon does this:
>
> if (chown(chrootStoreDir.c_str(), 0, buildUser.getGID()) == -1)
> throw SysError(format("cannot change ownership of ‘%1%’") % chrootStoreDir);
>
> So we can just remove the UID/GID from the directives that are in (gnu
> build install).
Done in a separate commit.
>
>> +(define* (genimage config target)
>> + "Use genimage to generate in TARGET directory, the image described in the
>> +given CONFIG file."
>> + ;; genimage needs a 'root' directory.
>> + (mkdir "root")
>> + (invoke "genimage" "--config" config
>> + "--outputpath" target))
>
> I had missed that bit, so we still need genimage in the end?
genimage is used to assemble the disk-image together. It's a matter of
doing some 'dd' with the right offset. Once this part is implemented in
(gnu build image), we can get rid of genimage.
>> +(define (register-bootcfg-root target bootcfg)
>> + "On file system TARGET, register BOOTCFG as a GC root."
>> + (let ((directory (string-append target "/var/guix/gcroots")))
>> + (mkdir-p directory)
>> + (symlink bootcfg (string-append directory "/bootcfg"))))
>
> Maybe just ‘register-gc-root’?
Turns out, I don't think this is useful anymore, so I removed it.
>
>> +(define* (register-closure prefix closure
>> + #:key
>> + (deduplicate? #t) (reset-timestamps? #t)
>> + (schema (sql-schema)))
>> + "Register CLOSURE in PREFIX, where PREFIX is the directory name of the
>> +target store and CLOSURE is the name of a file containing a reference graph as
>> +produced by #:references-graphs.. As a side effect, if RESET-TIMESTAMPS? is
>> +true, reset timestamps on store files and, if DEDUPLICATE? is true,
>> +deduplicates files common to CLOSURE and the rest of PREFIX."
>> + (let ((items (call-with-input-file closure read-reference-graph)))
>> + (register-items items
>> + #:prefix prefix
>> + #:deduplicate? deduplicate?
>> + #:reset-timestamps? reset-timestamps?
>> + #:registration-time %epoch
>> + #:schema schema)))
>
> This is duplicated from (guix build vm). Should we instead factorize it
> in (guix build store-copy)?
I tried it. The problem is that it introduces a dependency to
guile-sqlite3, so a bunch of with-extensions needs to be added in
various places. I kept the copy, as (gnu build vm) will be
deprecated/removed anyways.
> I’d suggest either ‘srfi-1:’ as the prefix or, better, hide whichever
> binding is causing a name clash.
I need partition from srfi-1 and partition from (gnu image). That's not
great :( I opted for the srfi-1 prefix as you suggested.
> Can we use ‘computed-file’ as well instead of ‘gexp->derivation’? That
> way, the API is entirely non-monadic and hopefully easier to use.
Ok, so I used computed-file as suggested. However, the "system-image"
procedure is calling the monadic system-disk-image-in-vm. So I had to
keep this one monadic.
The good news is once, system-disk-image-in-vm is no longer needed, this
whole file will be entirely non-monadic.
> That’s all!
Thanks a lot for going though all of this.
Mathieu
next prev parent reply other threads:[~2020-05-05 13:56 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-29 8:38 [bug#40955] [PATCH 0/5] Add new image API Mathieu Othacehe
2020-04-29 8:47 ` [bug#40955] [PATCH 1/5] build: store-copy: Export file-size procedure Mathieu Othacehe
2020-04-29 8:47 ` [bug#40955] [PATCH 2/5] build: install: Ignore chown exceptions Mathieu Othacehe
2020-05-02 11:09 ` Ludovic Courtès
2020-05-05 13:42 ` Mathieu Othacehe
2020-04-29 8:47 ` [bug#40955] [PATCH 3/5] build: bootloader: Add install-efi procedure Mathieu Othacehe
2020-05-02 12:16 ` Ludovic Courtès
2020-05-05 13:43 ` Mathieu Othacehe
2020-04-29 8:47 ` [bug#40955] [PATCH 4/5] image: Add a new API Mathieu Othacehe
2020-05-02 12:50 ` Ludovic Courtès
2020-05-05 13:52 ` Mathieu Othacehe [this message]
2020-05-02 13:02 ` Tobias Geerinckx-Rice via Guix-patches via
2020-05-05 14:12 ` Mathieu Othacehe
2020-04-29 8:47 ` [bug#40955] [PATCH 5/5] vm: Remove obsolete procedures Mathieu Othacehe
2020-05-02 12:52 ` Ludovic Courtès
2020-05-05 14:02 ` Mathieu Othacehe
2020-05-05 14:16 ` bug#40955: " Mathieu Othacehe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pnbicwv5.fsf@gmail.com \
--to=m.othacehe@gmail.com \
--cc=40955@debbugs.gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).