guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Status update on 1.0


From: Timothy Sample
Subject: Re: Status update on 1.0
Date: Thu, 21 Mar 2019 14:49:13 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Hi Ludo,

Ludovic Courtès <address@hidden> writes:

>> Yes.  We should be working on “guix size gnome-shell”.  It more
>> accurately reflects the size of GDM, and (I hope you’re sitting down) it
>> weighs in at 2GiB!
>>
>> Fortunately, it looks like we could claw back ~400MiB by (somehow)
>> dropping “hplip-minimal”.  It gets pulled in through the path
>>
>>     gdm → gnome-settings-daemon → colord → sane-backends →
>>     hplip-minimal.
>>
>> We almost certainly don’t need it for GDM.  I guess removing it means
>> making a version of “colord” without “sane-backends”.  It was introduced
>> in commit 4c9287432824f396d5c614c3b2287f553cd9fb90.  I’ll look into
>> this.
>
> Cool!  That’d already be an improvement.

This didn’t work as well as I had hoped.  I was able to make a “lib”
output for “colord”, which gets rid of “hplip-minimal” and, in turn,
“gcc”.  However, it was supposed to also remove “llvm” and address@hidden,
but those are still in the closure because of other packages.  It looks
like breaking apart “mesa” (as Debian and Nix do) could cut out “llvm”
and maybe address@hidden  The reason address@hidden is there is because of
“glib:bin”.  The “gnome-session” package brings it in so that it can
call “gsettings”.  Debian splits the GLib executables into “bin” and
“dev-bin”, and only the latter needs Python 3.  This is tricky because
“mesa” and “glib” have thousands of dependants, 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 “libnm” part, but it ends up bringing in everything.  NetworkManager
doesn’t 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 “inkscape” and
>> “webkitgtk” that are huge and (I assume) unnecessary.
>
> Oh indeed.  Inkscape comes from
> 45fef894eb5b39029633cd0cd907e8ce8c5ab379, I’ll look into it.

I managed to remove “webgitgtk” from the closure of “gnome-shell”.
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’s
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’t know
how much of this we can solve before 1.0.  It all depends on how much of
a hurry we’re 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’t 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’t be able to do any of it
before next weekend (Mar. 29).


-- Tim



reply via email to

[Prev in Thread] Current Thread [Next in Thread]