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

[宋文武]

address@hidden (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:

0001-gnu-nautilus-Don-t-propagate-gtk.patch
Description: Text Data

(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.