From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: should gnome-desktop-service really provide all of this to a profile? Date: Tue, 08 Mar 2016 17:35:42 +0100 Message-ID: <87fuw1j5b5.fsf@gnu.org> References: <87y49u70eo.fsf@pobox.com> <87si0256y9.fsf@gnu.org> <87ziu94ap7.fsf@igalia.com> <87pov5nxdo.fsf@gnu.org> <87ziu9yrbl.fsf@member.fsf.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]:49118) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adKbx-0003Aa-Em for guix-devel@gnu.org; Tue, 08 Mar 2016 11:35:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1adKbr-00033x-82 for guix-devel@gnu.org; Tue, 08 Mar 2016 11:35:53 -0500 In-Reply-To: <87ziu9yrbl.fsf@member.fsf.org> (=?utf-8?B?IuWui+aWh+atpiIn?= =?utf-8?B?cw==?= message of "Tue, 08 Mar 2016 22:31:10 +0800") 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: =?utf-8?B?5a6L5paH5q2m?= Cc: guix-devel@gnu.org iyzsong@member.fsf.org (=E5=AE=8B=E6=96=87=E6=AD=A6) skribis: > 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 i= t=E2=80=99s an application > after all, and adding input =E2=80=98gtk+=E2=80=99 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=E2=80=94e.g., =E2=80=9Cdoc=E2=80=9D outp= ut for xcb.) > It seems that multiple outputs doesn=E2=80=99t help here. Multiple outputs do help here: propagating libxcb:out only propagates libxcb:out, and not libxcb:doc. > For example, install =E2=80=98gtk+:doc=E2=80=99 into the profile will bri= ng all > propagated-inputs of =E2=80=98gtk+=E2=80=99 into profile too, because > propagated-inputs aren=E2=80=99t per output=E2=80=A6 Right, it=E2=80=99s a limitation that we could fix. It=E2=80=99s rarely a problem though, because usually when you install the = =E2=80=9Cdoc=E2=80=9D or =E2=80=9Cdebug=E2=80=9D output, you also want the rest, including propag= ated inputs. > 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 incl= uded when > install into the profile. Two things here: =E2=80=A2 Back in the day, I couldn=E2=80=99t think of a situation where = it would make sense for =E2=80=98propagated-inputs=E2=80=99 to be different from =E2=80=98propagated-user-env-packages=E2=80=99 (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. =E2=80=A2 I found the =E2=80=98nix-support=E2=80=99 trick (that is, havin= g 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 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 =E2=80=98gnome=E2=80=99 meta-packa= ge 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 insta= ll all the > individuals. If it=E2=80=99s a union and filter from other packages, I w= on=E2=80=99t > think it =E2=80=98meta=E2=80=99 anymore :-) Right. :-) > 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 p= ackages > 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=98sh= are/man=E2=80=99. > > - now install glibc into it, since glibc doesn=E2=80=99t have =E2=80=98sh= are/man=E2=80=99, > it only extend the =E2=80=98bin=E2=80=99 extension, so its binaries are= added to the > profile. >=20=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 libr= aries 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 ;-) Interesting ideas! There are connections with how search paths work currently. Anyway, what do you think would be the best way to avoid =E2=80=9Cprofile pollution=E2=80=9D with the GNOME meta-package? Thanks, Ludo=E2=80=99.