emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#65550: closed (Don't add propagated-inputs for all outputs)


From: GNU bug Tracking System
Subject: bug#65550: closed (Don't add propagated-inputs for all outputs)
Date: Sat, 02 Sep 2023 00:43:02 +0000

Your message dated Sat, 02 Sep 2023 08:43:01 +0800
with message-id <871qfhiewa.fsf@envs.net>
and subject line Re: bug#65550: Don't add propagated-inputs for all outputs
has caused the debbugs.gnu.org bug report #65550,
regarding Don't add propagated-inputs for all outputs
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
65550: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65550
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: Don't add propagated-inputs for all outputs Date: Sat, 26 Aug 2023 19:36:05 +0800
Hello, we have a TODO for "extend `propagated-inputs` with support for
multiple outputs".  I try to do it for a while, but unable to find a
clear way, since add a new syntax for specify output in
propagated-inputs require changes in too many places..

Think about the intention, what we want is to avoid unwanted
propagated-inputs for building a package or user profiles, and
propagated-inputs is mostly used for development packages which
requiring headers/libraries from its inputs.  It seems I can hardcode
the choice here to the "dev" output (if a package have both "dev" and
"out", its "out" should considered be an application) or the "out"
output (a library/development package).


Then the change is straight:

>From 98a8666a0cbf33e24efff615243b98144a92c950 Mon Sep 17 00:00:00 2001
Message-ID: 
<98a8666a0cbf33e24efff615243b98144a92c950.1693047369.git.iyzsong@member.fsf.org>
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= <iyzsong@member.fsf.org>
Date: Sat, 26 Aug 2023 18:27:09 +0800
Subject: [PATCH] packages: Don't propagate inputs for non-development package
 outputs.

* guix/packages.scm (transitive-inputs): Only include propagated inputs from a
package for its "dev" output, or its "out" output if the package doesn't have
a "dev" one.
---
 guix/packages.scm | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/guix/packages.scm b/guix/packages.scm
index ba98bb0fb4..435d55de71 100644
--- a/guix/packages.scm
+++ b/guix/packages.scm
@@ -1143,7 +1143,13 @@ (define (transitive-inputs inputs)
            (loop rest result propagated first? seen)
            (loop rest
                  (cons input result)
-                 (cons (package-propagated-inputs package) propagated)
+                 ;; Only add propagated inputs for PACKAGE:dev, or PACKAGE:out
+                 ;; when PACKAGE doesn't have a "dev" output.
+                 (if (if (member "dev" (package-outputs package))
+                         (member "dev" outputs)
+                         (or (null? outputs) (member "out" outputs)))
+                     (cons (package-propagated-inputs package) propagated)
+                     propagated)
                  first?
                  (vhash-consq package outputs seen))))
       ((input rest ...)

base-commit: eeb71d778f149834015858467fbeeb1276d96d1d
-- 
2.41.0


Not much benifits now, but i think it will helps when we have more
mulitple outputs packages.  Also how about add a slimming team aiming to
reduce the closure size of packages and system, anyone interested?

Thanks. 🥳

--- End Message ---
--- Begin Message --- Subject: Re: bug#65550: Don't add propagated-inputs for all outputs Date: Sat, 02 Sep 2023 08:43:01 +0800 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Hi,
>
> 宋文武 <iyzsong@envs.net> writes:
>
> [...]
>
>>> I think we'd need to evaluate what we'd gain in terms of size reduction
>>> a bit more carefully before moving in this direction and how it'd impact
>>> the user experience.  E.g., if we can reduce the minimal Guix image size
>>> by maybe 30%, that'd be nice, but if we're talking of about 5% like in
>>> your example profile, it doesn't seem worth the complexity to me.
>>
>> I agree, thanks Maxim and Liliana for the inputs!
>
> Should we close this issue for now?

Yes, closing.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]