Re: should gnome-desktop-service really provide all of this to a profile?

[iyzsong@member.fsf.org (宋文武)]

[-- Attachment #1: Type: text/plain, Size: 3574 bytes --]

ludo@gnu.org (Ludovic Courtès) writes:

> Pulseaudio also propagates a few things.
Yes, I think it should be splited into “out” and “dev”, if we can make
only the “dev” output propagating libcap and gdbm.
>
>>>>> Good point, this sounds undesirable (and shows that some packages would
>>>>> benefit from separate outputs—e.g., “doc” output for xcb.)
>> It seems that multiple outputs doesn’t help here.
>
> Multiple outputs do help here: propagating libxcb:out only propagates
> libxcb:out, and not libxcb:doc.
OK, but here we don’t want libxcb at all :-)
>
>> For example, install ‘gtk+:doc’ into the profile will bring all
>> propagated-inputs of ‘gtk+’ into profile too, because
>> propagated-inputs aren’t per output…
>
> Right, it’s a limitation that we could fix.
>
> It’s rarely a problem though, because usually when you install the “doc”
> or “debug” output, you also want the rest, including propagated
> inputs.
>
>> IIUC, in nix, it’s handled by writing files to specified output:
>> ‘$out/nix-support/propagated-build-inputs’
>> ‘$out/nix-support/propagated-native-build-inputs’
>> ‘$out/nix-support/propagated-user-env-packages’
>>
>> And only items in ‘propagated-user-env-packages’ are included when
>> install into the profile.
>
> Two things here:
>
>   • Back in the day, I couldn’t think of a situation where it would make
>     sense for ‘propagated-inputs’ to be different from
>     ‘propagated-user-env-packages’ (at the time, the latter was little
>     known so in practice people had to install dependencies by
>     themselves.)  So in Guix I chose to have just one.
In nix ‘propagated-build-inputs’ is propagations and ‘inputs’ for building
while ‘propagated-user-env-packages’ is propagations for profile.
In guix ‘propagated-inputs’ is propagations for both building and profile
and at the same time is ‘inputs’ for building.
I agree that propagations for building or for profile is the same thing,
and there’re some runtime only dependencies worthing treating as
non-inputs (eg: adwaita-icon-themes, plugins for gstreamer).

How about seperating propagations from ‘propagated-inputs’?
This requires listing some packages twice, but I think it will be more
clear considering ‘inputs’ are for building the whole package while
‘propagations’ are (should be) per-output.

eg:
--8<---------------cut here---------------start------------->8---
(package
  (name "pulseaudio")
  (outputs '("out" "include" "lib" "dev"))
  (inputs
   `(("libpcap" ,libcap)
     ("gdbm" ,gdmb)
     ...))
  (propagations
    #:output "dev"
    `(("pulseaudio:include" ,pulseaudio "include")
      ("pulseaudio:lib"     ,pulseaudio "lib")
      ("libpcap" ,libpcap)
      ("gdbm" ,gdbm)))
  ...)
--8<---------------cut here---------------end--------------->8---

>
>   • I found the ‘nix-support’ trick (that is, having high-level
>     information on the build side) kind of hacky, which is why this
>     information is solely on the build side in Guix.  This is what
>     allows higher-level functionality such as --search-paths to be
>     implemented on the host side.
>
>     OTOH, things like <http://bugs.gnu.org/22138> could be more easily
>     addressed if all the info was already on the build side.
Agree :-)
>
>
> […]
> Anyway, what do you think would be the best way to avoid “profile
> pollution” with the GNOME meta-package?
I think, for now:

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-gnu-nautilus-Don-t-propagate-gtk.patch --]
[-- Type: text/x-patch, Size: 1312 bytes --]

From 7206310f7320ed99eabd7f774a083c7b1f78c81f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= <iyzsong@gmail.com>
Date: Wed, 9 Mar 2016 13:17:48 +0800
Subject: [PATCH] gnu: nautilus: Don't propagate gtk+.

This reduces "profile pollution" of the 'gnome' meta package.
See <http://lists.gnu.org/archive/html/guix-devel/2016-03/msg00283.html>.

* gnu/packages/gnome.scm (nautilus): Move gtk+ from propagated-inputs to inputs.
---
 gnu/packages/gnome.scm | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index c945c0e..68218f6 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -4635,13 +4635,12 @@ as SASL, TLS and VeNCrypt.  Additionally it supports encoding extensions.")
        ("gobject-introspection" ,gobject-introspection)
        ("intltool" ,intltool)
        ("pkg-config" ,pkg-config)))
-    (propagated-inputs
-     `(("gtk+" ,gtk+))) ; required by libnautilus-extension.pc
     (inputs
      ;; TODO: add gvfs support.
      `(("dconf" ,dconf)
        ("exempi" ,exempi)
        ("gnome-desktop" ,gnome-desktop)
+       ("gtk+" ,gtk+) ; XXX: required by libnautilus-extension.pc
        ("libexif" ,libexif)
        ("libxml2" ,libxml2)))
     (synopsis "File manager for GNOME")
-- 
2.6.3


[-- Attachment #3: Type: text/plain, Size: 280 bytes --]

(Actually, I’m ok with a polluted profile.
And the ‘xfce’ propagates gtk+ by exo too.)

Next is to make propagations (and ‘search-paths’?) per-output.

And we can add some filter (based on search-paths or services
extensions?) to profile for hide unwanted files.