From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: Re: Status update on 1.0 Date: Sat, 23 Mar 2019 17:42:09 +0100 Message-ID: <87pnqhwnj2.fsf@gnu.org> References: <871s3a4xd4.fsf@gnu.org> <87k1h2p0v1.fsf@ngyro.com> <87a7hw45ca.fsf@gnu.org> <87ef70xdue.fsf@ngyro.com> 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]:56504) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7jim-0007Sf-5I for guix-devel@gnu.org; Sat, 23 Mar 2019 12:42:13 -0400 In-Reply-To: <87ef70xdue.fsf@ngyro.com> (Timothy Sample's message of "Thu, 21 Mar 2019 14:49:13 -0400") 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: Timothy Sample Cc: Guix-devel Hello! Timothy Sample skribis: > 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-min= imal=E2=80=9D and, in turn, > =E2=80=9Cgcc=E2=80=9D. However, it was supposed to also remove =E2=80=9C= llvm=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 c= ut 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 = brings it in so that it can > call =E2=80=9Cgsettings=E2=80=9D. Debian splits the GLib executables int= o =E2=80=9Cbin=E2=80=9D and > =E2=80=9Cdev-bin=E2=80=9D, and only the latter needs Python 3. This is t= ricky because > =E2=80=9Cmesa=E2=80=9D and =E2=80=9Cglib=E2=80=9D have thousands of depen= dants, so changing them could > cause a lot of problems. Splitting GLib is not so bad, but Mesa looks > to be quite complicated. Yeah, splitting MESA and GLib are longer-term project I guess, but it=E2=80= =99s good that you=E2=80=99ve already analyzed the situation so we know what to = do next. > 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. = NetworkManager > doesn=E2=80=99t have many dependants, so this could be done pretty quickly > (provided that splitting it is easy enough). Indeed. > I managed to remove =E2=80=9Cwebgitgtk=E2=80=9D from the closure of =E2= =80=9Cgnome-shell=E2=80=9D. Neat! Do you have that patch around? :-) > 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= know > how much of this we can solve before 1.0. It all depends on how much of > a hurry we=E2=80=99re in. :) That will be post-1.0, let=E2=80=99s focus on the low-hanging fruits for no= w. :-) > 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). OK, thank you for your work! Ludo=E2=80=99.