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

[ludo@gnu.org (Ludovic Courtès)]

iyzsong@member.fsf.org (宋文武) skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Andy Wingo <wingo@igalia.com> skribis:
>>
>>> On Mon 07 Mar 2016 22:11, ludo@gnu.org (Ludovic Courtès) writes:
>>>
>>>> Andy Wingo <wingo@pobox.com> skribis:
>>>>
>>>>> I installed gnome using
>>>>>
>>>>>   guix package --profile=/tmp/foo-profile -i gnome
>>>>>
>>>>> There is a lot of stuff there.  If gnome-desktop-service extends
>>>>> profile-service-type with gnome, will that not "pollute" a lot of
>>>>> profiles?  Attached is a listing of that profile.
>>>>> […]
> These mostly come from ‘nautilus’, which propagated ‘gtk+’.
> I think it’s ok to remove ‘gtk+’ from it, since it’s an application
> after all, and adding input ‘gtk+’ to other (libnautilus using) packages
> is trivial.

Pulseaudio also propagates a few things.

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

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

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

> I think we should make propagated things per output too.

Yes.

>> Right.  I think we should rewrite the ‘gnome’ meta-package in terms of
>> ‘union-build’ and explicitly include only bin/ and share/.
> Install a ‘meta’ package should have same effect as install all the
> individuals.  If it’s a union and filter from other packages, I won’t
> think it ‘meta’ anymore :-)

Right.  :-)

> Ideally, for every file in a purity profile, we know the reason why it
> exist.  Maybe it’s possible to implement by using services?  If packages
> could declare extensions and extend each other, when install packages
> into the profile, those services extensions are fold together.  I think:
>
> - by default, an empty profile only cares ‘bin’.
>   install man-db to it, will add an extension which cares for ‘share/man’.
>
> - now install glibc into it, since glibc doesn’t have ‘share/man’,
>   it only extend the ‘bin’ extension, so its binaries are added to the
>   profile.
>   
> - then install gcc into the profile, it care for ‘include’ and ‘lib’,
>   and have ‘share/man’, its manpages and headers and libraries of glibc
>   will appear.
>
> - at this point, remove man-db from profile will remove the gcc manpages
>   from it too.
>
> Then I dream what’s cool is that we could know and show users more
> information if all the relations between packages are coded explicitly
> by services extensions:
>
> - query (guix package –-show) man-db:
>    name: man-db
>    extensions:
>      man-page: interest ‘share/man’
>
> - install gcc:
>    The following package will be extended:
>      man-db (man-page)
>    The following package extend gcc:
>      glibc (header library)
>
> And perhaps other things ;-)

Interesting ideas!  There are connections with how search paths work
currently.

Anyway, what do you think would be the best way to avoid “profile
pollution” with the GNOME meta-package?

Thanks,
Ludo’.