iyzs...@member.fsf.org (宋文武) skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Andy Wingo <wi...@igalia.com> skribis:
>>
>>> On Mon 07 Mar 2016 22:11, l...@gnu.org (Ludovic Courtès) writes:
>>>
>>>> Andy Wingo <wi...@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’.
