* Canonical-packages restoration.
@ 2020-06-09 10:22 Mathieu Othacehe
2020-06-09 11:18 ` Jan Nieuwenhuizen
2020-06-09 16:34 ` Ludovic Courtès
0 siblings, 2 replies; 6+ messages in thread
From: Mathieu Othacehe @ 2020-06-09 10:22 UTC (permalink / raw)
To: guix-devel
Hello,
With f30d84d32db0f4f6cb84e139868e1727a7dc0a51 and
dfc8ccbf5da96a67eb1cade499f0def21e7fdb02, I did remove most of the
"canonical-package" calls because they were breaking system
cross-compilation.
Now, I'd like to somehow restore them, using the new "let-system". My
idea is to define something like:
--8<---------------cut here---------------start------------->8---
(define (canonical-package* package)
(let ((canonical
(module-ref (resolve-interface '(gnu packages base))
'canonical-package)))
(let-system (system target)
(if target
package
(canonical package)))))
--8<---------------cut here---------------end--------------->8---
And then use for instance this way:
--8<---------------cut here---------------start------------->8---
diff --git a/gnu/system/locale.scm b/gnu/system/locale.scm
index 689d238d1a..fd50538e9a 100644
--- a/gnu/system/locale.scm
+++ b/gnu/system/locale.scm
@@ -106,7 +106,8 @@ of LIBC."
;; 'localedef' executes 'gzip' to access compressed locale sources.
(setenv "PATH"
- (string-append #+gzip "/bin:" #+libc "/bin"))
+ (string-append #+gzip "/bin:"
+ #+(canonical-package* libc) "/bin"))
--8<---------------cut here---------------end--------------->8---
However, it seems that nesting a "let-system" inside "file-append" does
not work:
--8<---------------cut here---------------start------------->8---
(use-modules (guix))
(use-modules (gnu))
(run-with-store (open-connection)
(mlet* %store-monad
((drv (lower-object
(computed-file "computed"
#~(begin
(mkdir #$output)
(symlink #$(file-append
(let-system (s t) glibc) "/bin")
(string-append #$output "/ref"))))))
(output -> (derivation->output-path drv)))
(mbegin %store-monad
(built-derivations (list drv))
(return (format #t "~a~%" output)))))
--8<---------------cut here---------------end--------------->8---
and it prevents me from going further. Does this stuff make any sense?
If yes I can try to fix it, but I just want to be sure first :)
Thanks,
Mathieu
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: Canonical-packages restoration.
2020-06-09 10:22 Canonical-packages restoration Mathieu Othacehe
@ 2020-06-09 11:18 ` Jan Nieuwenhuizen
2020-06-09 11:30 ` Mathieu Othacehe
2020-06-09 16:34 ` Ludovic Courtès
1 sibling, 1 reply; 6+ messages in thread
From: Jan Nieuwenhuizen @ 2020-06-09 11:18 UTC (permalink / raw)
To: Mathieu Othacehe; +Cc: guix-devel
Mathieu Othacehe writes:
> With f30d84d32db0f4f6cb84e139868e1727a7dc0a51 and
> dfc8ccbf5da96a67eb1cade499f0def21e7fdb02, I did remove most of the
> "canonical-package" calls because they were breaking system
> cross-compilation.
>
> Now, I'd like to somehow restore them
Just a quick question: why?; would that reduce a system's closure size?
Janneke
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Canonical-packages restoration.
2020-06-09 11:18 ` Jan Nieuwenhuizen
@ 2020-06-09 11:30 ` Mathieu Othacehe
0 siblings, 0 replies; 6+ messages in thread
From: Mathieu Othacehe @ 2020-06-09 11:30 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: guix-devel
Hey Jan,
> Just a quick question: why?; would that reduce a system's closure size?
Yes mostly, even if the gains are not huge (~100MiB). However, I feel
like its easier the tackle the system closure size issue if we get rid
of the "noise".
Thanks,
Mathieu
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Canonical-packages restoration.
2020-06-09 10:22 Canonical-packages restoration Mathieu Othacehe
2020-06-09 11:18 ` Jan Nieuwenhuizen
@ 2020-06-09 16:34 ` Ludovic Courtès
2020-06-10 9:35 ` Mathieu Othacehe
1 sibling, 1 reply; 6+ messages in thread
From: Ludovic Courtès @ 2020-06-09 16:34 UTC (permalink / raw)
To: Mathieu Othacehe; +Cc: guix-devel
Hi,
Mathieu Othacehe <othacehe@gnu.org> skribis:
> With f30d84d32db0f4f6cb84e139868e1727a7dc0a51 and
> dfc8ccbf5da96a67eb1cade499f0def21e7fdb02, I did remove most of the
> "canonical-package" calls because they were breaking system
> cross-compilation.
>
> Now, I'd like to somehow restore them, using the new "let-system".
What if, instead, we removed those “canonical” packages entirely from
the reference graph? Do you think that’s an option?
> My idea is to define something like:
>
> (define (canonical-package* package)
> (let ((canonical
> (module-ref (resolve-interface '(gnu packages base))
> 'canonical-package)))
> (let-system (system target)
> (if target
> package
> (canonical package)))))
Aren’t there pieces of code that expect these things to be <package>
records?
> However, it seems that nesting a "let-system" inside "file-append" does
> not work:
>
> (use-modules (guix))
> (use-modules (gnu))
>
> (run-with-store (open-connection)
> (mlet* %store-monad
> ((drv (lower-object
> (computed-file "computed"
> #~(begin
> (mkdir #$output)
> (symlink #$(file-append
> (let-system (s t) glibc) "/bin")
> (string-append #$output "/ref"))))))
> (output -> (derivation->output-path drv)))
> (mbegin %store-monad
> (built-derivations (list drv))
> (return (format #t "~a~%" output)))))
>
> and it prevents me from going further. Does this stuff make any sense?
> If yes I can try to fix it, but I just want to be sure first :)
Bah yes, that’s why initially I didn’t push ‘let-system’:
https://issues.guix.gnu.org/29296#4
Perhaps we could avoid the expander = #f special case.
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Canonical-packages restoration.
2020-06-09 16:34 ` Ludovic Courtès
@ 2020-06-10 9:35 ` Mathieu Othacehe
2020-06-10 15:24 ` Ludovic Courtès
0 siblings, 1 reply; 6+ messages in thread
From: Mathieu Othacehe @ 2020-06-10 9:35 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 1512 bytes --]
Hey Ludo!
> What if, instead, we removed those “canonical” packages entirely from
> the reference graph? Do you think that’s an option?
It seems to be a better option! So, as I did remove most of the explicit
references to 'canonical-packages' the only references left are
implicit.
A good example is "isc-dhcp", that refers to implicit canonical inputs
"coreutils" and "sed" in the "dhclient-script". The attached patch fixes
it. I could do the same for a few other packages and it should fix the
issue.
The problem is that approach is not very long-term. Maybe we should take
a step back. Would it be an option to add all the canonical-packages as
disallowed-references? Or could we use implicit inputs that are not
rooted in the bootstrap chain?
>> My idea is to define something like:
>>
>> (define (canonical-package* package)
>> (let ((canonical
>> (module-ref (resolve-interface '(gnu packages base))
>> 'canonical-package)))
>> (let-system (system target)
>> (if target
>> package
>> (canonical package)))))
>
> Aren’t there pieces of code that expect these things to be <package>
> records?
Yes, but I was planning to change that, not a good idea after all.
> Bah yes, that’s why initially I didn’t push ‘let-system’:
>
> https://issues.guix.gnu.org/29296#4
>
> Perhaps we could avoid the expander = #f special case.
Ok, I will try to fix it then.
Thanks,
Mathieu
[-- Attachment #2: patch --]
[-- Type: application/octet-stream, Size: 1593 bytes --]
diff --git a/gnu/packages/admin.scm b/gnu/packages/admin.scm
index 77981e520a..537b162ba8 100644
--- a/gnu/packages/admin.scm
+++ b/gnu/packages/admin.scm
@@ -1004,10 +1004,10 @@ connection alive.")
;; if finds all the programs it needs.
(let* ((out (assoc-ref outputs "out"))
(libexec (string-append out "/libexec"))
- (coreutils (assoc-ref inputs "coreutils"))
+ (coreutils (assoc-ref inputs "coreutils*"))
(inetutils (assoc-ref inputs "inetutils"))
(net-tools (assoc-ref inputs "net-tools"))
- (sed (assoc-ref inputs "sed")))
+ (sed (assoc-ref inputs "sed*")))
(substitute* "client/scripts/linux"
(("/sbin/ip")
(string-append (assoc-ref inputs "iproute")
@@ -1047,12 +1047,8 @@ connection alive.")
(base32
"0vws0zzb39mkphj4hhjrgfj9dzw951lc4pfa6pqg5ll5ma51mbsr"))))
- ;; When cross-compiling, we need the cross Coreutils and sed.
- ;; Otherwise just use those from %FINAL-INPUTS.
- ,@(if (%current-target-system)
- `(("coreutils" ,coreutils)
- ("sed" ,sed))
- '())))
+ ("coreutils*" ,coreutils)
+ ("sed*" ,sed)))
(home-page "https://www.isc.org/products/DHCP/")
(synopsis "Dynamic Host Configuration Protocol (DHCP) tools")
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: Canonical-packages restoration.
2020-06-10 9:35 ` Mathieu Othacehe
@ 2020-06-10 15:24 ` Ludovic Courtès
0 siblings, 0 replies; 6+ messages in thread
From: Ludovic Courtès @ 2020-06-10 15:24 UTC (permalink / raw)
To: Mathieu Othacehe; +Cc: guix-devel
Hi,
Mathieu Othacehe <othacehe@gnu.org> skribis:
>> What if, instead, we removed those “canonical” packages entirely from
>> the reference graph? Do you think that’s an option?
>
> It seems to be a better option! So, as I did remove most of the explicit
> references to 'canonical-packages' the only references left are
> implicit.
>
> A good example is "isc-dhcp", that refers to implicit canonical inputs
> "coreutils" and "sed" in the "dhclient-script". The attached patch fixes
> it. I could do the same for a few other packages and it should fix the
> issue.
Yes, sounds good to me!
> The problem is that approach is not very long-term. Maybe we should take
> a step back. Would it be an option to add all the canonical-packages as
> disallowed-references?
Hmm yes, we could try that, but there’ll probably be many changes to
make.
> Or could we use implicit inputs that are not rooted in the bootstrap
> chain?
The problem is not that they’re rooted in the bootstrap chain (they
necessary build-depend on the bootstrap chain, but they’re guaranteed
not to have references to it). The problem is that we have two copies
of all these: coreutils-final vs. coreutils, guile-final vs. guile, etc.
As things are, it seems hard to avoid.
>> Bah yes, that’s why initially I didn’t push ‘let-system’:
>>
>> https://issues.guix.gnu.org/29296#4
>>
>> Perhaps we could avoid the expander = #f special case.
>
> Ok, I will try to fix it then.
No rush though, we can do that anytime.
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-06-10 15:31 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-09 10:22 Canonical-packages restoration Mathieu Othacehe
2020-06-09 11:18 ` Jan Nieuwenhuizen
2020-06-09 11:30 ` Mathieu Othacehe
2020-06-09 16:34 ` Ludovic Courtès
2020-06-10 9:35 ` Mathieu Othacehe
2020-06-10 15:24 ` Ludovic Courtès
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.