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

[宋文武]

address@hidden (Ludovic Courtès) writes:

> Andy Wingo <address@hidden> skribis:
>
>> On Mon 07 Mar 2016 22:11, address@hidden (Ludovic Courtès) writes:
>>
>>> Andy Wingo <address@hidden> 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.

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

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.

I think we should make propagated things per output too.
>>>
>>> What exactly is required?  Would it work to change the ‘gnome’
>>> meta-package to union only the bin/ sub-directories instead of
>>> everything?
>>
>> I do not know.  What I would want would be just the binaries and
>> anything needed in share/.  It would be great if there were no
>> development-related files there, as that's the only area where I care
>> about "purity" or "pollution".  Something seems to be propagating
>> libraries into the profile.
>
> 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 :-)

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 ;-)