From mboxrd@z Thu Jan 1 00:00:00 1970 From: Timothy Sample Subject: Re: Status update on 1.0 Date: Thu, 21 Mar 2019 14:49:13 -0400 Message-ID: <87ef70xdue.fsf@ngyro.com> References: <871s3a4xd4.fsf@gnu.org> <87k1h2p0v1.fsf@ngyro.com> <87a7hw45ca.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 ([209.51.188.92]:49300) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h72m1-00075m-Oc for guix-devel@gnu.org; Thu, 21 Mar 2019 14:50:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h72ki-0007xM-8S for guix-devel@gnu.org; Thu, 21 Mar 2019 14:49:21 -0400 In-Reply-To: <87a7hw45ca.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Fri, 15 Mar 2019 14:47:33 +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" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: Guix-devel Hi Ludo, Ludovic Court=C3=A8s writes: >> Yes. We should be working on =E2=80=9Cguix size gnome-shell=E2=80=9D. = It more >> accurately reflects the size of GDM, and (I hope you=E2=80=99re sitting = down) it >> weighs in at 2GiB! >> >> Fortunately, it looks like we could claw back ~400MiB by (somehow) >> dropping =E2=80=9Chplip-minimal=E2=80=9D. It gets pulled in through the= path >> >> gdm =E2=86=92 gnome-settings-daemon =E2=86=92 colord =E2=86=92 sane-= backends =E2=86=92 >> hplip-minimal. >> >> We almost certainly don=E2=80=99t need it for GDM. I guess removing it = means >> making a version of =E2=80=9Ccolord=E2=80=9D without =E2=80=9Csane-backe= nds=E2=80=9D. It was introduced >> in commit 4c9287432824f396d5c614c3b2287f553cd9fb90. I=E2=80=99ll look i= nto >> this. > > Cool! That=E2=80=99d already be an improvement. This didn=E2=80=99t work as well as I had hoped. I was able to make a =E2= =80=9Clib=E2=80=9D output for =E2=80=9Ccolord=E2=80=9D, which gets rid of =E2=80=9Chplip-minim= al=E2=80=9D and, in turn, =E2=80=9Cgcc=E2=80=9D. However, it was supposed to also remove =E2=80=9Cll= vm=E2=80=9D and =E2=80=9Cpython@3=E2=80=9D, but those are still in the closure because of other packages. It looks like breaking apart =E2=80=9Cmesa=E2=80=9D (as Debian and Nix do) could cut= out =E2=80=9Cllvm=E2=80=9D and maybe =E2=80=9Cpython@2=E2=80=9D. The reason =E2=80=9Cpython@3=E2=80= =9D is there is because of =E2=80=9Cglib:bin=E2=80=9D. The =E2=80=9Cgnome-session=E2=80=9D package br= ings it in so that it can call =E2=80=9Cgsettings=E2=80=9D. Debian splits the GLib executables into = =E2=80=9Cbin=E2=80=9D and =E2=80=9Cdev-bin=E2=80=9D, and only the latter needs Python 3. This is tri= cky because =E2=80=9Cmesa=E2=80=9D and =E2=80=9Cglib=E2=80=9D have thousands of dependa= nts, so changing them could cause a lot of problems. Splitting GLib is not so bad, but Mesa looks to be quite complicated. Another area that could be improved is NetworkManager. GDM only needs the =E2=80=9Clibnm=E2=80=9D part, but it ends up bringing in everything. N= etworkManager doesn=E2=80=99t have many dependants, so this could be done pretty quickly (provided that splitting it is easy enough). >> GNOME Shell has a handful of silly references like =E2=80=9Cinkscape=E2= =80=9D and >> =E2=80=9Cwebkitgtk=E2=80=9D that are huge and (I assume) unnecessary. > > Oh indeed. Inkscape comes from > 45fef894eb5b39029633cd0cd907e8ce8c5ab379, I=E2=80=99ll look into it. I managed to remove =E2=80=9Cwebgitgtk=E2=80=9D from the closure of =E2=80= =9Cgnome-shell=E2=80=9D. Inkscape is still in there, though. Maybe converting the SVG to a PNG in a separate derivation would be an easy solution. All told, GDM is down to 1.2GiB, and GNOME Shell is 1.64GiB. That=E2=80=99s better, but not great. Plenty of GNOME software comes in big bundles where you get a daemon, a low-level D-Bus library, a high-level library, a GUI, and some utilities. Being able to break these up would improve the situation quite a bit, but it will be a lot of work. I don=E2=80=99t k= now how much of this we can solve before 1.0. It all depends on how much of a hurry we=E2=80=99re in. :) Right now, I have a bit testing to do with my current patches, and then maybe I could break up NetworkManager and fix the dependency cycle with GDM and GNOME Shell. If it can go through a core-updates cycle, I could split up GLib. I don=E2=80=99t think I can split up Mesa, though. I am not very familiar with it. I will be tied up for about a week, so I won=E2=80=99t be able to do any of= it before next weekend (Mar. 29). -- Tim