From mboxrd@z Thu Jan 1 00:00:00 1970 From: iyzsong@member.fsf.org (=?utf-8?B?5a6L5paH5q2m?=) Subject: Re: should gnome-desktop-service really provide all of this to a profile? Date: Tue, 08 Mar 2016 22:31:10 +0800 Message-ID: <87ziu9yrbl.fsf@member.fsf.org> References: <87y49u70eo.fsf@pobox.com> <87si0256y9.fsf@gnu.org> <87ziu94ap7.fsf@igalia.com> <87pov5nxdo.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39025) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adIfi-0005pX-M9 for guix-devel@gnu.org; Tue, 08 Mar 2016 09:31:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1adIff-0007Dd-CZ for guix-devel@gnu.org; Tue, 08 Mar 2016 09:31:38 -0500 Received: from smtp13.openmailbox.org ([62.4.1.47]:53667) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adIff-0007Cz-6v for guix-devel@gnu.org; Tue, 08 Mar 2016 09:31:35 -0500 In-Reply-To: <87pov5nxdo.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Tue, 08 Mar 2016 10:15:47 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Andy Wingo skribis: > >> On Mon 07 Mar 2016 22:11, ludo@gnu.org (Ludovic Court=C3=A8s) writes: >> >>> Andy Wingo skribis: >>> >>>> I installed gnome using >>>> >>>> guix package --profile=3D/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. >>>> [=E2=80=A6] These mostly come from =E2=80=98nautilus=E2=80=99, which propagated =E2=80= =98gtk+=E2=80=99. I think it=E2=80=99s ok to remove =E2=80=98gtk+=E2=80=99 from it, since it= =E2=80=99s an application after all, and adding input =E2=80=98gtk+=E2=80=99 to other (libnautilus us= ing) packages is trivial. >>> >>> Good point, this sounds undesirable (and shows that some packages would >>> benefit from separate outputs=E2=80=94e.g., =E2=80=9Cdoc=E2=80=9D outpu= t for xcb.) It seems that multiple outputs doesn=E2=80=99t help here. For example, ins= tall =E2=80=98gtk+:doc=E2=80=99 into the profile will bring all propagated-input= s of =E2=80=98gtk+=E2=80=99 into profile too, because propagated-inputs aren=E2=80=99t per output=E2=80= =A6 IIUC, in nix, it=E2=80=99s handled by writing files to specified output: =E2=80=98$out/nix-support/propagated-build-inputs=E2=80=99 =E2=80=98$out/nix-support/propagated-native-build-inputs=E2=80=99 =E2=80=98$out/nix-support/propagated-user-env-packages=E2=80=99 And only items in =E2=80=98propagated-user-env-packages=E2=80=99 are includ= ed 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 =E2=80=98gnome= =E2=80=99 >>> 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 =E2=80=98gnome=E2=80=99 meta-packag= e in terms of > =E2=80=98union-build=E2=80=99 and explicitly include only bin/ and share/. Install a =E2=80=98meta=E2=80=99 package should have same effect as install= all the individuals. If it=E2=80=99s a union and filter from other packages, I won= =E2=80=99t think it =E2=80=98meta=E2=80=99 anymore :-) Ideally, for every file in a purity profile, we know the reason why it exist. Maybe it=E2=80=99s possible to implement by using services? If pac= kages 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 =E2=80=98bin=E2=80=99. install man-db to it, will add an extension which cares for =E2=80=98shar= e/man=E2=80=99. - now install glibc into it, since glibc doesn=E2=80=99t have =E2=80=98shar= e/man=E2=80=99, it only extend the =E2=80=98bin=E2=80=99 extension, so its binaries are a= dded to the profile. =20=20 - then install gcc into the profile, it care for =E2=80=98include=E2=80=99 = and =E2=80=98lib=E2=80=99, and have =E2=80=98share/man=E2=80=99, its manpages and headers and librar= ies of glibc will appear. - at this point, remove man-db from profile will remove the gcc manpages from it too. Then I dream what=E2=80=99s 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 =E2=80=93-show) man-db: name: man-db extensions: man-page: interest =E2=80=98share/man=E2=80=99 - install gcc: The following package will be extended: man-db (man-page) The following package extend gcc: glibc (header library) And perhaps other things ;-)