Re: Packages grow, no longer fit on a 

[Akib Azmain Turja]

b...@bokr.com writes:

> On +2023-01-20 23:34:53 +0600, Akib Azmain Turja wrote:
>> Csepp  writes:
>> 
>> I have a slow machine from about 10 years ago, and I'm really happy with
>> it.  (I'm writing from this machine.)  I also have a slow unstable
>> internet connection, so I understand the pain of download hundreds of
>> MB of data without pause and resume support.  (I couldn't download the
>> latest Guix GNU/Hurd QEMU image (just around 293 MB maybe?) even trying
>> 8-10 times.)
>>
>
> Could you somehow use
> wget -c 
> to continue an interrupted download?
> Or does the source not support that?

Yes, the infamous https://ci.guix.gnu.org server.

>
> (see wget --help |less -- and scroll down to Download: section)
>
>> -- 
>> Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
>> Fediverse: akib@hostux.social
>> Codeberg: akib
>> emailselfdefense.fsf.org | "Nothing can be secure without encryption."
>
> --
> Regards,
> Bengt Richter

-- 
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib@hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."


signature.asc
Description: PGP signature

Re: Packages grow, no longer fit on a 

[bokr]

On +2023-01-20 23:34:53 +0600, Akib Azmain Turja wrote:
> Csepp  writes:
> 
> I have a slow machine from about 10 years ago, and I'm really happy with
> it.  (I'm writing from this machine.)  I also have a slow unstable
> internet connection, so I understand the pain of download hundreds of
> MB of data without pause and resume support.  (I couldn't download the
> latest Guix GNU/Hurd QEMU image (just around 293 MB maybe?) even trying
> 8-10 times.)
>

Could you somehow use
wget -c 
to continue an interrupted download?
Or does the source not support that?

(see wget --help |less -- and scroll down to Download: section)

> -- 
> Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
> Fediverse: akib@hostux.social
> Codeberg: akib
> emailselfdefense.fsf.org | "Nothing can be secure without encryption."

--
Regards,
Bengt Richter

Re: Packages grow, no longer fit on a 

[Akib Azmain Turja]

Csepp  writes:

[...]

>>> It strikes me that this is like King Canute holding back the
>>> tide. Package size growth is pretty inevitable, and even if work now
>>> can bring the size down to that of a CD, the same problem will occur
>>> in the not too distant future.
>>>
>>
>> But we should really try to keep them low.
>>
>>> Is it really a problem?
>>
>> YES!
>>
>> Big packages means, it takes more space.  If a package grows by 700 MB,
>> installed on 10,000 computers, ~70 TB (70,000,000 MB) is wasted.  You
>> could use that precious storage to save your dad's photo, your favorite
>> music, your child's video calling you "daddy/mummy" for the first time,
>> etc.  You would need to get more storage for that storing those
>> invaluable things, so you would need more storage devices.  When you buy
>> more storage, the demand of increases, and therefore the manufacturing
>> of storage devices increase.  The more devices are manufactured, the
>> more carbon dioxide and other greenhouse gas emission.
>>
>> Again, if the packages is downloaded 100 times every day, ~70 GB (7
>> MB) of bandwidth is wasted every day.  Someone on the network could use
>> that to do some more important thing, like video calling a relative
>> living far away.  Moreover, it takes time to get the extra 700 MB for
>> everyone.  Assuming it takes 8 minutes on average, ~13.33 hours (800
>> minutes) of time is wasted everyday.  We have limited time in our lives,
>> we shouldn't waste the time.  This extra ~70 GB of transmission means
>> more load on the network, more load on the network devices, and
>> therefore more power consumption.  The more power consumption, the more
>> greenhouse gas emission, since we're fossil fuel dependent.  If your
>> country uses nuclear power, the extra nuclear waste is a threat for the
>> environment.
>>
>> The more greenhouse gas, the more greenhouse effect, the more global
>> warming, the more climate change.  You will just destroy the earth for
>> future yourself and the future generation.  What will you answer to
>> them?
>>
>>> Please educate me! :)
>>
>> It's my pleasure to make someone aware.
>> I hope this was enough.  :)
>> If not, just ask!
>>
>>>
>>> --
>>> Paul
>>>
>>>
>
> Well said.  Gonna add to this that developers are overwhelmingly from
> privileged backgrounds.  Just because we don't have a lot of users on
> the mailing list who have to use satellite internet on ancient laptops
> does not mean those (potential) users are not out there and wouldn't
> benefit from our distro not being a bloated mess.  Which sadly it kind
> of is currently.  I wholeheartedly recommend trying to use it on an old
> netbook or an armhf device from time to time.
> Like others have said: if you want to develop efficient software, use a
> slow machine.  :)

I have a slow machine from about 10 years ago, and I'm really happy with
it.  (I'm writing from this machine.)  I also have a slow unstable
internet connection, so I understand the pain of download hundreds of
MB of data without pause and resume support.  (I couldn't download the
latest Guix GNU/Hurd QEMU image (just around 293 MB maybe?) even trying
8-10 times.)

-- 
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib@hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."


signature.asc
Description: PGP signature

Re: Packages grow, no longer fit on a 

[Csepp]

Akib Azmain Turja  writes:

> [[PGP Signed Part:Undecided]]
> Paul Jewell via "Development of GNU Guix and the GNU System
> distribution."  writes:
>
>> Evening all,
>>
>> On 14/01/2023 23:07, Ludovic Courtès wrote:
>>> Hello!
>>> Over the course of a few years, the size of our packages has
>>> apparently
>>> kept growing.  Example:
>>> --8<---cut here---start->8---
>>> $ guix time-machine --commit=v1.2.0 -- size emacs
>>> store item   total
>>> self
>>> /gnu/store/118xpdazyylxa1rlc68h9lmh38vhxrb4-llvm-10.0.0210.8   
>>> 139.3  16.2%
>>> /gnu/store/1qmd9achfkm1njzxf8hi86q53pmy9sxk-mesa-20.0.7369.2   
>>> 131.3  15.3%
>>> /gnu/store/d83hc7cqgnhl1vlz1rv4ibkvaqaq2g35-emacs-27.1 859.7   
>>> 106.2  12.4%
>>> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2132.8
>>> 53.2   6.2%
>>> /gnu/store/9lckq1194qcy4a7kv8bihagd58shj7yr-gtk+-3.24.20   723.7
>>> 49.0   5.7%
>>> /gnu/store/qizplwwgqwyq6qmz1i6jlaib5kgzrgwq-icu4c-66.1 110.2
>>> 38.1   4.4%
>>> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31  38.4
>>> 36.7   4.3%
>>> […]
>>> total: 859.7 MiB
>>> $ guix time-machine --commit=v1.3.0 -- size emacs
>>> store item   total
>>> self
>>> /gnu/store/g3idjpqsp2p2d163qfzskxj4k58nrx7f-llvm-11.0.0220.0   
>>> 148.6  16.9%
>>> /gnu/store/jf269s6clr6r57p8v5c3c1qkyra6apq2-mesa-20.2.4389.1   
>>> 141.6  16.1%
>>> /gnu/store/7nlq2v4000pw8vgj3m4vrwz072ib58xh-emacs-27.2 880.5   
>>> 106.4  12.1%
>>> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2132.8
>>> 53.2   6.0%
>>> /gnu/store/czf23hay13pp25yzrb4yq3n4gcri5r70-gtk+-3.24.24   744.3
>>> 49.1   5.6%
>>> /gnu/store/2wqjj3mkqdvsvksndr2hpjpi7qqwi7kr-icu4c-66.1 110.2
>>> 38.1   4.3%
>>> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31  38.4
>>> 36.7   4.2%
>>> […]
>>> total: 880.5 MiB
>>> $ guix time-machine --commit=v1.4.0 -- size emacs
>>> store item   total
>>> self
>>> /gnu/store/i11jmrc90drpx9mc6cyb6s4pjny91qx6-emacs-28.21592.7   
>>> 250.6  15.7%
>>> /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8411.6   
>>> 169.6  10.6%
>>> /gnu/store/6pdzpmxg5afzss6dlivq8z84sfa31x22-llvm-11.0.0221.5   
>>> 149.5   9.4%
>>> /gnu/store/lphzb1z0r4kbb453rsvnw7msrxxzp5r7-libgccjit-10.3.0   244.8   
>>> 128.5   8.1%
>>> /gnu/store/pfas3c4lhr1jwkj2gl0yx8dg4xjjlp4r-mozjs-91.13.0  261.2
>>> 65.4   4.1%
>>> /gnu/store/hy6abswwv4d89zp464fw52z65fkzr7h5-perl-5.34.0147.7
>>> 58.6   3.7%
>>> /gnu/store/zyqimpkmpffc24nwwqp46cicj8ss85y5-binutils-2.37  126.0
>>> 54.4   3.4%
>>> /gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7129.1
>>> 52.0   3.3%
>>> /gnu/store/4aq7hw017s9ihpm1rxpwfz28c80569z9-gtk+-3.24.30  1002.2
>>> 48.6   3.1%
>>> /gnu/store/vaxkf8cbc7slgc3ikm5qr3815wih93w8-ghostscript-with-cups-9.54.0   
>>> 219.139.1   2.5%
>>> /gnu/store/bjycxjjkp1da53ijsa4hfdrz9mcgg55h-icu4c-69.1 110.7
>>> 38.0   2.4%
>>> /gnu/store/ayc9r7162rphy4zjw8ch01pmyh214h82-glibc-2.33  76.6
>>> 36.6   2.3%
>>> […]
>>> total: 1592.7 MiB
>>> --8<---cut here---end--->8---
>>> I think something went wrong here.  :-)
>>> In particular with Emacs itself (due to JIT + dependency on
>>> libgccjit,
>>> Binutils, etc.?) and with GTK+ (due to mozjs in polkit?).
>>> And then MESA and LLVM have always been problematically big.
>>> We should do better.  I mean, it’s just a text editor, isn’t it?
>>> Ludo’.
>>> 
>>
>> Please forgive my ignorance if I have missed anything but:
>>
>> - does anyone actually install from a CD these days?
>
> I don't know, but I'd just use a pendrive if I need an external storage.
> (If I don't need, I'd just use a 2 GB HDD partition, which I made just
> for very purpose.  ;)  )
>
>> - Can an ISO be bigger than a CD then be installed on a memory stick?
>
> Yes.
>
>>
>> It strikes me that this is like King Canute holding back the
>> tide. Package size growth is pretty inevitable, and even if work now
>> can bring the size down to that of a CD, the same problem will occur
>> in the not too distant future.
>>
>
> But we should really try to keep them low.
>
>> Is it really a problem?
>
> YES!
>
> Big packages means, it takes more space.  If a package grows by 700 MB,
> installed on 10,000 computers, ~70 TB (70,000,000 MB) is wasted.  You
> could use that precious storage to save your dad's photo, your favorite
> music, your child's video calling you "daddy/mummy" for the first time,
> etc.  You would need to get more storage for that storing those
> invaluable things, so you would need more storage 

Re: Packages grow, no longer fit on a 

[Maxim Cournoyer]

Hi,

Simon Tournier  writes:

[...]

> Yeah for sure. :-) Although, from my point of view, the main issue is
> about a policy for package inclusion; I mean there is no secret: light
> images means images with less features. :-)
>
> My personal and biased opinion is that Guix should follow minimalist
> packages as default packages and provides more variants.  But the
> maintenance cost is not free, IMHO. :-)

My personal take on this would be to start with fixing *bugs* like
#25235 (Wrapped python programs get native-inputs in PYTHONPATH) that
surely contributes to larger graphs, pulling purely build time
dependencies in the graph (there's a fix proposed in the same thread).
This one is for Python, but the same must apply to other scripting
languages that rely on wrap phases.  The pulling of large debug outputs
just to graft locally is also annoying, but that wouldn't end up in the
image produced, right?

I don't think deduplication is turned on for all the images produced by
guix pack such as Docker, which would mean grafts have a heavy cost
there.

Other idea: move the static libraries detected to a static output
automatically when a "static" output is declared, else remove them, in
the gnu-build-system standard phases.

While I agree we can do better, in general I don't think we can compete
with Alpine, which appears to aim for minimalism at the expense of
features.  I don't think GNU Guix is about that kind of minimalism; it
aims to empower its users through full-featured and well documented
packages.  I also think it's nice to ship at least the info/man pages
documentation in the main output in general, even if it makes our
packages slightly larger than on Alpine, and stripping include files in
a different output seems a pain to deal with, from a user perspective.

I guess what I'm saying is that there seems to be larger and lower
hanging fruits to collect before we start micro-managing package
outputs.

-- 
Thanks,
Maxim

Re: Packages grow, no longer fit on a 

[Simon Tournier]

Hi,

On mer., 18 janv. 2023 at 21:44, Paul Jewell via "Development of GNU Guix and 
the GNU System distribution."  wrote:

> - does anyone actually install from a CD these days?
> - Can an ISO be bigger than a CD then be installed on a memory stick?

Florian reported an example in [1], quoting:

my laptop doesn’t boot from USB, I have more CD/Rs than DVD/Rs
and I guess they are cheaper than DVD.

1: 


> It strikes me that this is like King Canute holding back the tide. 
> Package size growth is pretty inevitable, and even if work now can bring 
> the size down to that of a CD, the same problem will occur in the not 
> too distant future.
>
> Is it really a problem? Please educate me! :)

>From my point of view, yes this increases is an issue, especially for
the not too distant future.  In the short term, we have to save
resources because in this not too distant future, we will have to do
the same (or more) using less.


Cheers,
simon

Re: Packages grow, no longer fit on a 

[Simon Tournier]

Hi,

On jeu., 19 janv. 2023 at 15:32, Ludovic Courtès  wrote:

>> I also wonder how much of the space is taken by debug output. Would
>> making graft derivations substitutable help?
>
> Graft derivations are not substitutable because it’s usually faster to
> “build” them locally than to download them (it depends on package size,
> hard disk performance, and network performance; my experience with an
> SSD is that grafting is always faster than downloading, even over FTTH.)

Recently, I built a large profile with oulà many many grafts and my
machine spent some time for that.

Would it be possible to substitute the result after applying grafts?


Cheers,
simon

Re: Packages grow, no longer fit on a 

[Simon Tournier]

Hi Ludo,

On jeu., 19 janv. 2023 at 15:14, Ludovic Courtès  wrote:

> To me, Emacs is still Emacs, with or without libgccjit.  Of course JIT
> is an improvement, I don’t deny that, but what I mean is that I still
> use Emacs for the very same activities.  This is even more true for
> polkit, because I don’t interact directly with it.

Yeah, there is a trade-off for the maintenance between packages that the
most of us want and specialized packages for user’s own needs.

This reminds me past discussions about parameterized packages. ;-)

Well, for instance the scientific package ’gmsh’ is built full featured
– with GUI using ’fltk’.  That’s a feature that requires big
dependencies; when I mainly use it without GUI.

Another example, git-annex is built full featured – able to run the
WebApp for instance.  That’s a feature that requires a increase of 5%;
when I mainly use a very restricted set of Git-Annex features.

Another instance, the closure of Guix increases a lot from 1.2 to 1.4.
Of course the new version provides many improvements, I do not deny
that, but I still use Guix for the very same activities as I am doing
since version 1.2. ;-)

The tacit policy with Guix packages is that the packages are usually by
default “feature maximalist” or specifically named « -minimal » …

> Right, and reportedly, Alpine-based images for things like Python are
> smaller than what we do.  There’s no cheating here: images are
> self-contained.

…contrary to Alpine where the packages are usually by default “feature
minimalist” or specifically named « - ».

Consider the package Emacs [1] and give a look at the recipe for the
package named ’emacs’ [2].  Well, this Alpine package ’emacs’ looks like
the Guix package named ’emacs-minimal’, and then Alpine provides these
variants (subpackages):

emacs-doc
emacs-gtk3
emacs-gtk3-nativecomp
emacs-nox
emacs-x11
emacs-x11-nativecomp

1: 
2: 

> Maybe a good topic for a sub-group at the Guix Days?  :-)

Yeah for sure. :-) Although, from my point of view, the main issue is
about a policy for package inclusion; I mean there is no secret: light
images means images with less features. :-)

My personal and biased opinion is that Guix should follow minimalist
packages as default packages and provides more variants.  But the
maintenance cost is not free, IMHO. :-)

Cheers,
simon

Re: Packages grow, no longer fit on a 

[Akib Azmain Turja]

Paul Jewell via "Development of GNU Guix and the GNU System
distribution."  writes:

> Evening all,
>
> On 14/01/2023 23:07, Ludovic Courtès wrote:
>> Hello!
>> Over the course of a few years, the size of our packages has
>> apparently
>> kept growing.  Example:
>> --8<---cut here---start->8---
>> $ guix time-machine --commit=v1.2.0 -- size emacs
>> store item   total
>> self
>> /gnu/store/118xpdazyylxa1rlc68h9lmh38vhxrb4-llvm-10.0.0210.8   
>> 139.3  16.2%
>> /gnu/store/1qmd9achfkm1njzxf8hi86q53pmy9sxk-mesa-20.0.7369.2   
>> 131.3  15.3%
>> /gnu/store/d83hc7cqgnhl1vlz1rv4ibkvaqaq2g35-emacs-27.1 859.7   
>> 106.2  12.4%
>> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2132.8
>> 53.2   6.2%
>> /gnu/store/9lckq1194qcy4a7kv8bihagd58shj7yr-gtk+-3.24.20   723.7
>> 49.0   5.7%
>> /gnu/store/qizplwwgqwyq6qmz1i6jlaib5kgzrgwq-icu4c-66.1 110.2
>> 38.1   4.4%
>> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31  38.4
>> 36.7   4.3%
>> […]
>> total: 859.7 MiB
>> $ guix time-machine --commit=v1.3.0 -- size emacs
>> store item   total
>> self
>> /gnu/store/g3idjpqsp2p2d163qfzskxj4k58nrx7f-llvm-11.0.0220.0   
>> 148.6  16.9%
>> /gnu/store/jf269s6clr6r57p8v5c3c1qkyra6apq2-mesa-20.2.4389.1   
>> 141.6  16.1%
>> /gnu/store/7nlq2v4000pw8vgj3m4vrwz072ib58xh-emacs-27.2 880.5   
>> 106.4  12.1%
>> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2132.8
>> 53.2   6.0%
>> /gnu/store/czf23hay13pp25yzrb4yq3n4gcri5r70-gtk+-3.24.24   744.3
>> 49.1   5.6%
>> /gnu/store/2wqjj3mkqdvsvksndr2hpjpi7qqwi7kr-icu4c-66.1 110.2
>> 38.1   4.3%
>> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31  38.4
>> 36.7   4.2%
>> […]
>> total: 880.5 MiB
>> $ guix time-machine --commit=v1.4.0 -- size emacs
>> store item   total
>> self
>> /gnu/store/i11jmrc90drpx9mc6cyb6s4pjny91qx6-emacs-28.21592.7   
>> 250.6  15.7%
>> /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8411.6   
>> 169.6  10.6%
>> /gnu/store/6pdzpmxg5afzss6dlivq8z84sfa31x22-llvm-11.0.0221.5   
>> 149.5   9.4%
>> /gnu/store/lphzb1z0r4kbb453rsvnw7msrxxzp5r7-libgccjit-10.3.0   244.8   
>> 128.5   8.1%
>> /gnu/store/pfas3c4lhr1jwkj2gl0yx8dg4xjjlp4r-mozjs-91.13.0  261.2
>> 65.4   4.1%
>> /gnu/store/hy6abswwv4d89zp464fw52z65fkzr7h5-perl-5.34.0147.7
>> 58.6   3.7%
>> /gnu/store/zyqimpkmpffc24nwwqp46cicj8ss85y5-binutils-2.37  126.0
>> 54.4   3.4%
>> /gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7129.1
>> 52.0   3.3%
>> /gnu/store/4aq7hw017s9ihpm1rxpwfz28c80569z9-gtk+-3.24.30  1002.2
>> 48.6   3.1%
>> /gnu/store/vaxkf8cbc7slgc3ikm5qr3815wih93w8-ghostscript-with-cups-9.54.0   
>> 219.139.1   2.5%
>> /gnu/store/bjycxjjkp1da53ijsa4hfdrz9mcgg55h-icu4c-69.1 110.7
>> 38.0   2.4%
>> /gnu/store/ayc9r7162rphy4zjw8ch01pmyh214h82-glibc-2.33  76.6
>> 36.6   2.3%
>> […]
>> total: 1592.7 MiB
>> --8<---cut here---end--->8---
>> I think something went wrong here.  :-)
>> In particular with Emacs itself (due to JIT + dependency on
>> libgccjit,
>> Binutils, etc.?) and with GTK+ (due to mozjs in polkit?).
>> And then MESA and LLVM have always been problematically big.
>> We should do better.  I mean, it’s just a text editor, isn’t it?
>> Ludo’.
>> 
>
> Please forgive my ignorance if I have missed anything but:
>
> - does anyone actually install from a CD these days?

I don't know, but I'd just use a pendrive if I need an external storage.
(If I don't need, I'd just use a 2 GB HDD partition, which I made just
for very purpose.  ;)  )

> - Can an ISO be bigger than a CD then be installed on a memory stick?

Yes.

>
> It strikes me that this is like King Canute holding back the
> tide. Package size growth is pretty inevitable, and even if work now
> can bring the size down to that of a CD, the same problem will occur
> in the not too distant future.
>

But we should really try to keep them low.

> Is it really a problem?

YES!

Big packages means, it takes more space.  If a package grows by 700 MB,
installed on 10,000 computers, ~70 TB (70,000,000 MB) is wasted.  You
could use that precious storage to save your dad's photo, your favorite
music, your child's video calling you "daddy/mummy" for the first time,
etc.  You would need to get more storage for that storing those
invaluable things, so you would need more storage devices.  When you buy
more storage, the demand of increases, and therefore the manufacturing
of storage devices increase.  The more devices are manufactured, the
more carbon dioxide and other 

Re: Packages grow, no longer fit on a 

[Katherine Cox-Buday]

Ludovic Courtès  writes:

> Even from a purely practical perspective, it’s not convenient when
> ‘guix pack’ creates big images that you have to carry around and your
> colleague laughs at you because their Alpine image of “the same thing”
> (quotes!) is half the size. ;-)

I know this pain!

-- 
Katherine

Re: Packages grow, no longer fit on a 

[Katherine Cox-Buday]

John Kehayias  writes:

>>> Efraim Flashner  skribis:
>>>
>>> I've made some progress on LLVM and I think I have a working LLVM
>>> that can be used as an input for mesa.

This is awesome! Thank you Efraim!

> I don't think there were any errors in building mesa with older LLVM,
> but on current hardware (unfortunately brings in non-free
> considerations) this was necessary. I believe this is the summary:
> 

I can confirm that 3D acceleration would not work until LLVM-15 was
used. I don't understand the entire rendering pipeline anymore, but I
think it had something to do with Vulkan.

> Props to katco on IRC for going through some long building and
> debugging to track this down.

Thanks, John!

Part of the reason this was difficult to test (aside from having to
discover the LLVM part) was discovering that the XORG_DRI_DRIVER_PATH
environment variable wasn't being set correctly despite doing package
rewriting to use a different version of Mesa.

I ended up doing this:

--8<---cut here---start->8---
(define-public (xorg-with-mesa xorg-server mesa)
  "Returns an xorg-server package which will wrap the call to Xorg to include 
the
correct XORG_DRI_DRIVER_PATH for the mesa package provided."
  (package
   (inherit xorg-server)
   (arguments
(substitute-keyword-arguments
 (package-arguments xorg-server)
 ((#:phases child-phases '%standard-phases)
  #~(modify-phases #$child-phases
   (add-after 'install 'wrap
  (lambda* (#:key outputs #:allow-other-keys)
(let* ((out (assoc-ref outputs "out"))
   (bin (string-append out "/bin"))
   (xorg (string-append bin "/Xorg")))
  (wrap-program xorg
'("XORG_DRI_DRIVER_PATH" 
":" = (#$(file-append mesa "/lib/dri")
--8<---cut here---end--->8---

But something like this (I'm sure I've gotten the gexps wrong) would have been 
made it much easier:

--8<---cut here---start->8---
diff --git a/gnu/services/xorg.scm b/gnu/services/xorg.scm
index 5f073d05d3..d626e87073 100644
--- a/gnu/services/xorg.scm
+++ b/gnu/services/xorg.scm
@@ -196,7 +196,9 @@ (define-record-type* 
   (server   xorg-configuration-server ;file-like
 (default xorg-server))
   (server-arguments xorg-configuration-server-arguments ;list of strings
-(default %default-xorg-server-arguments)))
+(default %default-xorg-server-arguments))
+  (mesa xorg-configuration-mesa ; package
+(default mesa)))
 
 (define (xorg-configuration->file config)
   "Compute an Xorg configuration file corresponding to CONFIG, an
@@ -362,7 +364,7 @@ (define* (xorg-wrapper #:optional (config 
(xorg-configuration)))
   (define exp
 ;; Write a small wrapper around the X server.
 #~(begin
-(setenv "XORG_DRI_DRIVER_PATH" (string-append #$mesa "/lib/dri"))
+(setenv "XORG_DRI_DRIVER_PATH" (string-append 
#$(xorg-configuration-mesa config) "/lib/dri"))
 (setenv "XKB_BINDIR" (string-append #$xkbcomp "/bin"))
 
 (let ((X (string-append #$(xorg-configuration-server config) 
"/bin/X")))
--8<---cut here---end--->8---

--
Katherine

Re: Packages grow, no longer fit on a 

[Ludovic Courtès]

Hi,

Paul Jewell via "Development of GNU Guix and the GNU System
distribution."  skribis:

> - Can an ISO be bigger than a CD then be installed on a memory stick?

Yes, it can be installed from a memory stick, that’s probably what
everybody does.

> It strikes me that this is like King Canute holding back the
> tide. Package size growth is pretty inevitable, and even if work now
> can bring the size down to that of a CD, the same problem will occur
> in the not too distant future.

I’d like to question the extent to which this is inevitable, or at least
see what we can learn from others to try and mitigate disk usage growth.

Even from a purely practical perspective, it’s not convenient when ‘guix
pack’ creates big images that you have to carry around and your
colleague laughs at you because their Alpine image of “the same thing”
(quotes!) is half the size.  ;-)

Ludo’.

Re: Packages grow, no longer fit on a 

[Ludovic Courtès]

Simon Tournier  skribis:

> Just to note to Guix itself significantly grows. :-)

Yes!  There’s a lot of .scm and .go files in there, neither of which is
compact.

Ludo’.

Re: Packages grow, no longer fit on a 

[Ludovic Courtès]

Hi,

kiasoc5  skribis:

> We may wish to utilize multiple package outputs to a greater
> extent. Some Guix packages already have bin, doc, and lib outputs. We
> could make it a policy to split this for all packages.

There’s some a policy already, though maybe not universally followed;
see point 8 at
.

> I also wonder how much of the space is taken by debug output. Would
> making graft derivations substitutable help?

Graft derivations are not substitutable because it’s usually faster to
“build” them locally than to download them (it depends on package size,
hard disk performance, and network performance; my experience with an
SSD is that grafting is always faster than downloading, even over FTTH.)

Ludo’.

Re: Packages grow, no longer fit on a 

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On Tue, 17 Jan 2023 at 17:25, Ludovic Courtès  wrote:
>
>> Examples include libgccjit in Emacs and mozjs in polkit.
>
> Do I miss a point?  How is it possible to have native compilation for
> Emacs without libgccjit?

I wrote:

> there are also new big dependencies being pulled in for what, from a
> distance, doesn’t really add functionality.

To me, Emacs is still Emacs, with or without libgccjit.  Of course JIT
is an improvement, I don’t deny that, but what I mean is that I still
use Emacs for the very same activities.  This is even more true for
polkit, because I don’t interact directly with it.

> For emacs-minimal, if considered to only bytecompile (.elc) and not
> native compile, this libgccgit seems unexpected, indeed.  Well, is
> native compilation disabled for emacs-minimal?  I guess not. :-)

It should probably be disabled, yes.

>> Still, even compared to contemporary distros, we’re doing pretty bad.
>> Debian most likely does better, and people often cite Alpine as the
>> distro providing the smallest packages.  Do we have figures?  What can
>> we learn from them?  What tradeoffs to they make?
>
> I agree we need to improve.  However, I would like to mitigate. :-)
>
> Functional and closure makes apparent what is hard to evaluate on
> “contemporary distros”.  I would be curious to know the transitive
> closure of the testing Debian meta-package named ’emacs’ (28.2) [1],
> which is roughly the equivalent of the Guix package ’emacs’.

Yes, that’s the kind of figures we need.

> Because if you dig a bit [2], for instance it depends on ’libgccjit0’.
>
> If you consider Alpine Linux and give a look at the dependency of the
> equivalent [3] of the Guix package ’emacs’, it depends on ’libgccjit’.
>
> These “contemporary distros” rely on version resolver which somehow
> hides the costs; when these costs are clearly popping with Guix.
>
> For sure, we need to improve because Docker pack produced by Guix are
> really more fat compared to the ones available around and usually
> produced with distros as Alpine.

Right, and reportedly, Alpine-based images for things like Python are
smaller than what we do.  There’s no cheating here: images are
self-contained.

Maybe a good topic for a sub-group at the Guix Days?  :-)

Ludo’.

Re: Packages grow, no longer fit on a 

[Joshua Branson]

Paul Jewell via "Development of GNU Guix and the GNU System
distribution."  writes:

> Evening all,
>
>
> Please forgive my ignorance if I have missed anything but:
>
> - does anyone actually install from a CD these days?
> - Can an ISO be bigger than a CD then be installed on a memory stick?
>
> It strikes me that this is like King Canute holding back the tide. Package 
> size
> growth is pretty inevitable, and even if work now can bring the size down to
> that of a CD, the same problem will occur in the not too distant future.
>
> Is it really a problem? Please educate me! :)
>

Well if GNU Guix/Hurd System ever becomes a thing, you will need a CD to
install the Hurd.  The Hurd currently does not have usb support.  Though
work is ongoing to fix this.  Also the current Debian GNU/Hurd requires
a CD to install in real hardware.

>
> --
> Paul

Re: Packages grow, no longer fit on a 

[Development of GNU Guix and the GNU System distribution.]

Evening all,

On 14/01/2023 23:07, Ludovic Courtès wrote:

Hello!

Over the course of a few years, the size of our packages has apparently
kept growing.  Example:

--8<---cut here---start->8---
$ guix time-machine --commit=v1.2.0 -- size emacs
store item   totalself
/gnu/store/118xpdazyylxa1rlc68h9lmh38vhxrb4-llvm-10.0.0210.8   
139.3  16.2%
/gnu/store/1qmd9achfkm1njzxf8hi86q53pmy9sxk-mesa-20.0.7369.2   
131.3  15.3%
/gnu/store/d83hc7cqgnhl1vlz1rv4ibkvaqaq2g35-emacs-27.1 859.7   
106.2  12.4%
/gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2132.8
53.2   6.2%
/gnu/store/9lckq1194qcy4a7kv8bihagd58shj7yr-gtk+-3.24.20   723.7
49.0   5.7%
/gnu/store/qizplwwgqwyq6qmz1i6jlaib5kgzrgwq-icu4c-66.1 110.2
38.1   4.4%
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31  38.4
36.7   4.3%
[…]
total: 859.7 MiB
$ guix time-machine --commit=v1.3.0 -- size emacs
store item   totalself
/gnu/store/g3idjpqsp2p2d163qfzskxj4k58nrx7f-llvm-11.0.0220.0   
148.6  16.9%
/gnu/store/jf269s6clr6r57p8v5c3c1qkyra6apq2-mesa-20.2.4389.1   
141.6  16.1%
/gnu/store/7nlq2v4000pw8vgj3m4vrwz072ib58xh-emacs-27.2 880.5   
106.4  12.1%
/gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2132.8
53.2   6.0%
/gnu/store/czf23hay13pp25yzrb4yq3n4gcri5r70-gtk+-3.24.24   744.3
49.1   5.6%
/gnu/store/2wqjj3mkqdvsvksndr2hpjpi7qqwi7kr-icu4c-66.1 110.2
38.1   4.3%
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31  38.4
36.7   4.2%
[…]
total: 880.5 MiB
$ guix time-machine --commit=v1.4.0 -- size emacs
store item   totalself
/gnu/store/i11jmrc90drpx9mc6cyb6s4pjny91qx6-emacs-28.21592.7   
250.6  15.7%
/gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8411.6   
169.6  10.6%
/gnu/store/6pdzpmxg5afzss6dlivq8z84sfa31x22-llvm-11.0.0221.5   
149.5   9.4%
/gnu/store/lphzb1z0r4kbb453rsvnw7msrxxzp5r7-libgccjit-10.3.0   244.8   
128.5   8.1%
/gnu/store/pfas3c4lhr1jwkj2gl0yx8dg4xjjlp4r-mozjs-91.13.0  261.2
65.4   4.1%
/gnu/store/hy6abswwv4d89zp464fw52z65fkzr7h5-perl-5.34.0147.7
58.6   3.7%
/gnu/store/zyqimpkmpffc24nwwqp46cicj8ss85y5-binutils-2.37  126.0
54.4   3.4%
/gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7129.1
52.0   3.3%
/gnu/store/4aq7hw017s9ihpm1rxpwfz28c80569z9-gtk+-3.24.30  1002.2
48.6   3.1%
/gnu/store/vaxkf8cbc7slgc3ikm5qr3815wih93w8-ghostscript-with-cups-9.54.0   
219.139.1   2.5%
/gnu/store/bjycxjjkp1da53ijsa4hfdrz9mcgg55h-icu4c-69.1 110.7
38.0   2.4%
/gnu/store/ayc9r7162rphy4zjw8ch01pmyh214h82-glibc-2.33  76.6
36.6   2.3%
[…]
total: 1592.7 MiB
--8<---cut here---end--->8---

I think something went wrong here.  :-)

In particular with Emacs itself (due to JIT + dependency on libgccjit,
Binutils, etc.?) and with GTK+ (due to mozjs in polkit?).

And then MESA and LLVM have always been problematically big.

We should do better.  I mean, it’s just a text editor, isn’t it?

Ludo’.



Please forgive my ignorance if I have missed anything but:

- does anyone actually install from a CD these days?
- Can an ISO be bigger than a CD then be installed on a memory stick?

It strikes me that this is like King Canute holding back the tide. 
Package size growth is pretty inevitable, and even if work now can bring 
the size down to that of a CD, the same problem will occur in the not 
too distant future.


Is it really a problem? Please educate me! :)

--
Paul

Re: Packages grow, no longer fit on a 

[indieterminacy]

On 18-01-2023 03:41, kiasoc5 wrote:

On 1/17/23 11:25, Ludovic Courtès wrote:


There are slight increases of each and every package, and there are 
also
new big dependencies being pulled in for what, from a distance, 
doesn’t

really add functionality.

Examples include libgccjit in Emacs and mozjs in polkit.

In a way, that’s the “unavoidable” (?) evolution of software, and the
problem extends largely beyond Guix.

Still, even compared to contemporary distros, we’re doing pretty bad.
Debian most likely does better, and people often cite Alpine as the
distro providing the smallest packages.  Do we have figures?  What can
we learn from them?  What tradeoffs to they make?


We can achieve smaller packages by splitting them more. Here is my 
guess of the amount of package splitting by some distros, from least to 
most:


Slackware < Arch < Fedora < Debian < Alpine

- Slackware I believe does not split anything, everything is included.
- Arch splits packages on a case by case basis (QEMU for example)
- Fedora typically splits packages into package X and package X-devel, 
where X contains development headers, but usually not more.
- Debian splits packages more aggressively. For example libreoffice is 
split into 6 packages, 1 for each suite (draw, write, etc). And 
programs may be separated from their outputs (eg zstd and libzstd are 
split)
- Alpine splits even more aggressively, they also split out man pages 
and shell completions.


We may wish to utilize multiple package outputs to a greater extent. 
Some Guix packages already have bin, doc, and lib outputs. We could 
make it a policy to split this for all packages.


I also wonder how much of the space is taken by debug output. Would 
making graft derivations substitutable help?


https://lists.gnu.org/archive/html/help-guix/2022-10/msg00225.html


I think Guix is missing a trick here.

All this effort to chain everything with inputs and yet we are using 
conventional 'package-boxes'.


Why not 'Dutch Auction' it and set a maximum amount of inheritants 
within one package file and then iteratively lower the threshhold (over 
time!) until there are noises in the guix-devel ML

that this principal is being taken far.

The outcome could allow more of a layers and multifaceted representation 
of tools and applications that give more of a distinction between lower 
level utilities and applications.



--
Jonathan McHugh
indieterminacy@libre.brussels

Re: Packages grow, no longer fit on a 

[kiasoc5]

On 1/17/23 11:25, Ludovic Courtès wrote:


There are slight increases of each and every package, and there are also
new big dependencies being pulled in for what, from a distance, doesn’t
really add functionality.

Examples include libgccjit in Emacs and mozjs in polkit.

In a way, that’s the “unavoidable” (?) evolution of software, and the
problem extends largely beyond Guix.

Still, even compared to contemporary distros, we’re doing pretty bad.
Debian most likely does better, and people often cite Alpine as the
distro providing the smallest packages.  Do we have figures?  What can
we learn from them?  What tradeoffs to they make?


We can achieve smaller packages by splitting them more. Here is my guess 
of the amount of package splitting by some distros, from least to most:


Slackware < Arch < Fedora < Debian < Alpine

- Slackware I believe does not split anything, everything is included.
- Arch splits packages on a case by case basis (QEMU for example)
- Fedora typically splits packages into package X and package X-devel, 
where X contains development headers, but usually not more.
- Debian splits packages more aggressively. For example libreoffice is 
split into 6 packages, 1 for each suite (draw, write, etc). And programs 
may be separated from their outputs (eg zstd and libzstd are split)
- Alpine splits even more aggressively, they also split out man pages 
and shell completions.


We may wish to utilize multiple package outputs to a greater extent. 
Some Guix packages already have bin, doc, and lib outputs. We could make 
it a policy to split this for all packages.


I also wonder how much of the space is taken by debug output. Would 
making graft derivations substitutable help?


https://lists.gnu.org/archive/html/help-guix/2022-10/msg00225.html

Re: Packages grow, no longer fit on a 

[zimoun]

Hi,

On Tue, 17 Jan 2023 at 17:25, Ludovic Courtès  wrote:

> Examples include libgccjit in Emacs and mozjs in polkit.

Do I miss a point?  How is it possible to have native compilation for
Emacs without libgccjit?

For emacs-minimal, if considered to only bytecompile (.elc) and not
native compile, this libgccgit seems unexpected, indeed.  Well, is
native compilation disabled for emacs-minimal?  I guess not. :-)


> Still, even compared to contemporary distros, we’re doing pretty bad.
> Debian most likely does better, and people often cite Alpine as the
> distro providing the smallest packages.  Do we have figures?  What can
> we learn from them?  What tradeoffs to they make?

I agree we need to improve.  However, I would like to mitigate. :-)

Functional and closure makes apparent what is hard to evaluate on
“contemporary distros”.  I would be curious to know the transitive
closure of the testing Debian meta-package named ’emacs’ (28.2) [1],
which is roughly the equivalent of the Guix package ’emacs’.

Because if you dig a bit [2], for instance it depends on ’libgccjit0’.

If you consider Alpine Linux and give a look at the dependency of the
equivalent [3] of the Guix package ’emacs’, it depends on ’libgccjit’.

These “contemporary distros” rely on version resolver which somehow
hides the costs; when these costs are clearly popping with Guix.

For sure, we need to improve because Docker pack produced by Guix are
really more fat compared to the ones available around and usually
produced with distros as Alpine.

1: 
2: 
3: 


Cheers,
simon

Re: Packages grow, no longer fit on a 

[zimoun]

On Wed, 18 Jan 2023 at 00:05, zimoun  wrote:

> For emacs-minimal, if considered to only bytecompile (.elc) and not
> native compile, this libgccgit seems unexpected, indeed.  Well, is
> native compilation disabled for emacs-minimal?  I guess not. :-)

The package emacs-minimal is only for bytecompiling and configured
without native compilation, IIUC.  Thus the reference to libgccgit
appears unexpected, then tackled by Josselin and fixed by Liliana in
#60831 [1].

Cool! :-)

1: 



Cheers,
simon

Re: Packages grow, no longer fit on a 

[John Kehayias]

Hi all,

On Tue, Jan 17, 2023 at 05:18 PM, Ludovic Courtès wrote:

> Hi,
>
> Efraim Flashner  skribis:
>
>> I've made some progress on LLVM and I think I have a working LLVM that
>> can be used as an input for mesa.
>>
>> (ins)efraim@3900XT ~$ du -sch 
>> /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/*
>> 3.9M/gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/bin
>> 8.0K/gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/etc
>> 21M /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/include
>> 67M /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/lib
>> 16K /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/share
>> 92M total
>>
>> (define llvm-for-mesa
>>   (package/inherit llvm-11
>
> Yay, great news!  Let’s have that in ‘core-updates’.
>

Yes, very nice!

A note that after some debugging that latest mesa (22.2.3 as of today, to be 
updated on
core-updates) seems to want newer LLVM, namely llvm-15. Fortunately we have 
this LLVM
version thanks to other's hard work on this front.

I don't think there were any errors in building mesa with older LLVM, but on 
current
hardware (unfortunately brings in non-free considerations) this was necessary. 
I believe
this is the summary: 

Props to katco on IRC for going through some long building and debugging to 
track this
down. The end result is that mesa 22.2.x with llvm-15 gave proper support for 
current gen
hardware, both parts (and current kernel) being needed.

So, I'd vote for having llvm-for-mesa to be at the latest LLVM version as well 
as Mesa. As
per the discussion on another thread, this could make sense for a feature 
branch and to
get thorough testing. Seeing as how LLVM seems pretty core to what Mesa does 
these days, I
would feel better having that tested across different hardware and use cases. 
Again, I
think a singular feature branch works well for this and I'm happy to help out 
on that
front. But I'll leave those discussions to the other thread.

>> In addition to what I have below I found that nix has a patch to make
>> llvm-11 (and the others) use the GNUInstallDirs, so we'd be able to move
>> the include directory to another output, saving another 21MB, bringing
>> llvm-for-mesa down to 71MB. Another possibility would be to have
>> llvm-for-mesa use llvm as an input, and then to use some configure-flags
>> to tell llvm-for-mesa to use the includes from llvm (the input).
>
> Good.  We can make these changes incrementally, but having
> ‘llvm-for-mesa’ would already be a noticeable improvement.
>
> Thanks!
>
> Ludo’.

Thanks all, I'm here for smaller closures!
John

Re: Packages grow, no longer fit on a 

[Simon Tournier]

Hi,

On sam., 14 janv. 2023 at 23:07, Ludovic Courtès  wrote:

> --8<---cut here---start->8---
> $ guix time-machine --commit=v1.2.0 -- size emacs 

[...]

> total: 859.7 MiB
> $ guix time-machine --commit=v1.3.0 -- size emacs 

[...]

> total: 880.5 MiB
> $ guix time-machine --commit=v1.4.0 -- size emacs 

[...]

> total: 1592.7 MiB
> --8<---cut here---end--->8---
>
> I think something went wrong here.  :-)

[...]

> We should do better.  I mean, it’s just a text editor, isn’t it?

Just to note to Guix itself significantly grows. :-)

--8<---cut here---start->8---
$ for i in 2 3 4; do guix time-machine --commit=v1.$i.0 -- size guix 
--sort=self ;done
store item   totalself
/gnu/store/n8vdar2f60mvq62g7mngpqwykbm9rw1q-guix-1.2.0rc2-1.0d4b1af   496.0   
244.5  49.3%
/gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2132.8
53.2  10.7%
/gnu/store/ah16zr8mmfkqy23rr7jy5a842ca1q9h1-guile-3.0.4131.4
51.9  10.5%
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31  38.4
36.7   7.4%
/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib   71.0
32.6   6.6%
/gnu/store/z7a6sbvqzb5zapwpznmjkq2rsxil6i67-glibc-utf8-locales-2.3113.9
13.9   2.8%

[...]

total: 496.0 MiB
store item   totalself
/gnu/store/9r4954qlv3pszpb8g3h5q2yn1xkda8vm-guix-1.3.0rc2-1.566982b   564.8   
263.9  46.7%
/gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2132.8
53.2   9.4%
/gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5131.7
52.1   9.2%
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31  38.4
36.7   6.5%
/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib   71.0
32.6   5.8%
/gnu/store/qzj0j8lv58fyr7dbsjj4fzjcqvgmkwzb-glib-2.62.6110.3
14.7   2.6%
/gnu/store/rgydar9dfvflqqz2irgh7njj34amaxc6-glibc-utf8-locales-2.3113.9
13.9   2.5%

[...]

total: 564.8 MiB
store item   totalself
/gnu/store/9nvx97hr8kkr26gzwni2fblfn0yq0xjw-guix-1.4.0rc2  637.2   
330.1  51.8%
/gnu/store/qlmpcy5zi84m6dikq3fnx5dz38qpczlc-guile-3.0.8130.0
53.0   8.3%
/gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7129.1
52.0   8.2%
/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33  38.3
36.6   5.7%
/gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib  71.7
33.4   5.2%
/gnu/store/96srhmpmxa20wmsck95g3iq4hb3lz4a0-glib-2.70.2 98.1
15.3   2.4%
/gnu/store/mw3py6smb1pk8yx298hd9ivz9lzbksqi-glibc-utf8-locales-2.3313.9
13.9   2.2%

[...]

total: 637.2 MiB
--8<---cut here---end--->8---


Cheers,
simon

Re: Packages grow, no longer fit on a 

[Ludovic Courtès]

Hi,

"pelzflorian (Florian Pelz)"  skribis:

> Ludovic Courtès  writes:
>> Over the course of a few years, the size of our packages has apparently
>> kept growing.
>
> Disregarding dependencies, most store items got slightly bigger.  This
> is what I wrote at bug#58760 “Guix System iso too big for cdrom again”
> :
>
>> it was possible to burn the Guix System install image to a 700MB CD.
>> But it fits no more. I compared using the du tool (comparison between
>> good old Guix version e427593 and bad new Guix version 3734857f […]).
>> The result is that most packages got slightly bigger and this broke
>> the camel’s back.

There are slight increases of each and every package, and there are also
new big dependencies being pulled in for what, from a distance, doesn’t
really add functionality.

Examples include libgccjit in Emacs and mozjs in polkit.

In a way, that’s the “unavoidable” (?) evolution of software, and the
problem extends largely beyond Guix.

Still, even compared to contemporary distros, we’re doing pretty bad.
Debian most likely does better, and people often cite Alpine as the
distro providing the smallest packages.  Do we have figures?  What can
we learn from them?  What tradeoffs to they make?

I think package size is something we should work on.  I don’t feel good
knowing that ‘bare-bones.tmpl’ yields an OS that’s “equivalent” to
Debian from 20 years ago, yet consumes close to 1 GiB.

Thanks,
Ludo’.

Re: Packages grow, no longer fit on a 

[Ludovic Courtès]

Hi,

Efraim Flashner  skribis:

> I've made some progress on LLVM and I think I have a working LLVM that
> can be used as an input for mesa.
>
> (ins)efraim@3900XT ~$ du -sch 
> /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/*
> 3.9M/gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/bin
> 8.0K/gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/etc
> 21M /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/include
> 67M /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/lib
> 16K /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/share
> 92M total
>
> (define llvm-for-mesa
>   (package/inherit llvm-11

Yay, great news!  Let’s have that in ‘core-updates’.

> In addition to what I have below I found that nix has a patch to make
> llvm-11 (and the others) use the GNUInstallDirs, so we'd be able to move
> the include directory to another output, saving another 21MB, bringing
> llvm-for-mesa down to 71MB. Another possibility would be to have
> llvm-for-mesa use llvm as an input, and then to use some configure-flags
> to tell llvm-for-mesa to use the includes from llvm (the input).

Good.  We can make these changes incrementally, but having
‘llvm-for-mesa’ would already be a noticeable improvement.

Thanks!

Ludo’.

Re: Packages grow, no longer fit on a 

[Ludovic Courtès]

Maxim Cournoyer  skribis:

> [polkit] is already using duktape by default on core-updates, so that
> particular one is solved.

That’s a much welcome improvement!

--8<---cut here---start->8---
$ guix size mozjs | tail -1
total: 264.8 MiB
ludo@ribbon ~/src/guix [env]$ guix size duktape | tail -1
total: 72.4 MiB
--8<---cut here---end--->8---

Ludo’.

Re: Packages grow, no longer fit on a 

[Efraim Flashner]

On Sat, Jan 14, 2023 at 11:07:23PM +0100, Ludovic Courtès wrote:
> Hello!
> 
> Over the course of a few years, the size of our packages has apparently
> kept growing.  Example:
> 
> --8<---cut here---start->8---
> $ guix time-machine --commit=v1.2.0 -- size emacs 
> store item   totalself
> /gnu/store/118xpdazyylxa1rlc68h9lmh38vhxrb4-llvm-10.0.0210.8   
> 139.3  16.2%
> /gnu/store/1qmd9achfkm1njzxf8hi86q53pmy9sxk-mesa-20.0.7369.2   
> 131.3  15.3%
> /gnu/store/d83hc7cqgnhl1vlz1rv4ibkvaqaq2g35-emacs-27.1 859.7   
> 106.2  12.4%
> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2132.8
> 53.2   6.2%
> /gnu/store/9lckq1194qcy4a7kv8bihagd58shj7yr-gtk+-3.24.20   723.7
> 49.0   5.7%
> /gnu/store/qizplwwgqwyq6qmz1i6jlaib5kgzrgwq-icu4c-66.1 110.2
> 38.1   4.4%
> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31  38.4
> 36.7   4.3%
> […]
> total: 859.7 MiB
> $ guix time-machine --commit=v1.3.0 -- size emacs 
> store item   totalself
> /gnu/store/g3idjpqsp2p2d163qfzskxj4k58nrx7f-llvm-11.0.0220.0   
> 148.6  16.9%
> /gnu/store/jf269s6clr6r57p8v5c3c1qkyra6apq2-mesa-20.2.4389.1   
> 141.6  16.1%
> /gnu/store/7nlq2v4000pw8vgj3m4vrwz072ib58xh-emacs-27.2 880.5   
> 106.4  12.1%
> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2132.8
> 53.2   6.0%
> /gnu/store/czf23hay13pp25yzrb4yq3n4gcri5r70-gtk+-3.24.24   744.3
> 49.1   5.6%
> /gnu/store/2wqjj3mkqdvsvksndr2hpjpi7qqwi7kr-icu4c-66.1 110.2
> 38.1   4.3%
> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31  38.4
> 36.7   4.2%
> […]
> total: 880.5 MiB
> $ guix time-machine --commit=v1.4.0 -- size emacs 
> store item   totalself
> /gnu/store/i11jmrc90drpx9mc6cyb6s4pjny91qx6-emacs-28.21592.7   
> 250.6  15.7%
> /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8411.6   
> 169.6  10.6%
> /gnu/store/6pdzpmxg5afzss6dlivq8z84sfa31x22-llvm-11.0.0221.5   
> 149.5   9.4%
> /gnu/store/lphzb1z0r4kbb453rsvnw7msrxxzp5r7-libgccjit-10.3.0   244.8   
> 128.5   8.1%
> /gnu/store/pfas3c4lhr1jwkj2gl0yx8dg4xjjlp4r-mozjs-91.13.0  261.2
> 65.4   4.1%
> /gnu/store/hy6abswwv4d89zp464fw52z65fkzr7h5-perl-5.34.0147.7
> 58.6   3.7%
> /gnu/store/zyqimpkmpffc24nwwqp46cicj8ss85y5-binutils-2.37  126.0
> 54.4   3.4%
> /gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7129.1
> 52.0   3.3%
> /gnu/store/4aq7hw017s9ihpm1rxpwfz28c80569z9-gtk+-3.24.30  1002.2
> 48.6   3.1%
> /gnu/store/vaxkf8cbc7slgc3ikm5qr3815wih93w8-ghostscript-with-cups-9.54.0   
> 219.139.1   2.5%
> /gnu/store/bjycxjjkp1da53ijsa4hfdrz9mcgg55h-icu4c-69.1 110.7
> 38.0   2.4%
> /gnu/store/ayc9r7162rphy4zjw8ch01pmyh214h82-glibc-2.33  76.6
> 36.6   2.3%
> […]
> total: 1592.7 MiB
> --8<---cut here---end--->8---
> 
> I think something went wrong here.  :-)
> 
> In particular with Emacs itself (due to JIT + dependency on libgccjit,
> Binutils, etc.?) and with GTK+ (due to mozjs in polkit?).
> 
> And then MESA and LLVM have always been problematically big.
> 
> We should do better.  I mean, it’s just a text editor, isn’t it?

I've made some progress on LLVM and I think I have a working LLVM that
can be used as an input for mesa.

(ins)efraim@3900XT ~$ du -sch 
/gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/*
3.9M/gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/bin
8.0K/gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/etc
21M /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/include
67M /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/lib
16K /gnu/store/36kmnxmb1h8pxw0x71wril67fdvjx7ny-llvm-11.0.0/share
92M total

(define llvm-for-mesa
  (package/inherit llvm-11
;; If we can separate out the include directory we'd save another 21MB.
(outputs (list "out"))
(arguments
 (substitute-keyword-arguments (package-arguments llvm-11)
   ((#:configure-flags cf ''())
;; AMDGPU is needed by the vulkan drivers.
`(list ,(string-append "-DLLVM_TARGETS_TO_BUILD="
(system->llvm-target) ";AMDGPU")
   "-DLLVM_BUILD_TOOLS=NO"
   "-DLLVM_BUILD_LLVM_DYLIB=YES"
   "-DLLVM_LINK_LLVM_DYLIB=YES"))
   ((#:phases phases)
`(modify-phases ,phases
   (add-after 'install 'delete-static-libraries
 (lambda* (#:key outputs #:allow-other-keys)
   (for-each delete-file
 (find-files (string-append
   (assoc-ref outputs "out") "/lib")
  

Re: Packages grow, no longer fit on a 

[Maxim Cournoyer]

Hi Liliana,

Liliana Marie Prikler  writes:

> Am Sonntag, dem 15.01.2023 um 21:09 -0500 schrieb Maxim Cournoyer:
>> Hi,
>> 
>> Liliana Marie Prikler  writes:
>> 
>> [...]
>> 
>> > > We should do better.  I mean, it’s just a text editor, isn’t it?
>> > Well, gedit is also "just an editor" which weighs 1GB (compared to
>> > 880MB for Emacs) in v1.3.0 and 1.3GB in v1.4.0 (mozjs?).  I think
>> > we ought to look into duplicate references being kept (glibc, gcc),
>> > but we can't really work against packages including more inputs
>> > without reducing their feature set – in some cases we could try
>> > alternatives like mozjs vs. duktape for polkit.
>> 
>> mozjs is already using duktape by default on core-updates, so that
>> particular one is solved.
> s/mozjs/polkit/, right?

Indeed.  See commit e8f4e1808563eb3c1cd28d419a1f349412af4a0d for the
change.

-- 
Thanks,
Maxim

Re: Packages grow, no longer fit on a 

[Liliana Marie Prikler]

Am Sonntag, dem 15.01.2023 um 21:09 -0500 schrieb Maxim Cournoyer:
> Hi,
> 
> Liliana Marie Prikler  writes:
> 
> [...]
> 
> > > We should do better.  I mean, it’s just a text editor, isn’t it?
> > Well, gedit is also "just an editor" which weighs 1GB (compared to
> > 880MB for Emacs) in v1.3.0 and 1.3GB in v1.4.0 (mozjs?).  I think
> > we ought to look into duplicate references being kept (glibc, gcc),
> > but we can't really work against packages including more inputs
> > without reducing their feature set – in some cases we could try
> > alternatives like mozjs vs. duktape for polkit.
> 
> mozjs is already using duktape by default on core-updates, so that
> particular one is solved.
s/mozjs/polkit/, right?

Re: Packages grow, no longer fit on a 

[Maxim Cournoyer]

Hi,

Liliana Marie Prikler  writes:

[...]

>> We should do better.  I mean, it’s just a text editor, isn’t it?
> Well, gedit is also "just an editor" which weighs 1GB (compared to
> 880MB for Emacs) in v1.3.0 and 1.3GB in v1.4.0 (mozjs?).  I think we
> ought to look into duplicate references being kept (glibc, gcc), but we
> can't really work against packages including more inputs without
> reducing their feature set – in some cases we could try alternatives
> like mozjs vs. duktape for polkit.

mozjs is already using duktape by default on core-updates, so that
particular one is solved.

-- 
Thanks,
Maxim

Re: Packages grow, no longer fit on a 

[pelzflorian (Florian Pelz)]

Hello all.

Ludovic Courtès  writes:
> Over the course of a few years, the size of our packages has apparently
> kept growing.

Disregarding dependencies, most store items got slightly bigger.  This
is what I wrote at bug#58760 “Guix System iso too big for cdrom again”
:

> it was possible to burn the Guix System install image to a 700MB CD.
> But it fits no more. I compared using the du tool (comparison between
> good old Guix version e427593 and bad new Guix version 3734857f […]).
> The result is that most packages got slightly bigger and this broke
> the camel’s back.

Regards,
Florian

Re: Packages grow, no longer fit on a 

[Akib Azmain Turja]

Ludovic Courtès  writes:

> Hello!
>
> Over the course of a few years, the size of our packages has apparently
> kept growing.  Example:

Unless the right steps are taken at right time, the size of packages
will reach the largest real number in near future.

>
> $ guix time-machine --commit=v1.2.0 -- size emacs 
> store item   totalself
> /gnu/store/118xpdazyylxa1rlc68h9lmh38vhxrb4-llvm-10.0.0210.8   
> 139.3  16.2%
> /gnu/store/1qmd9achfkm1njzxf8hi86q53pmy9sxk-mesa-20.0.7369.2   
> 131.3  15.3%
> /gnu/store/d83hc7cqgnhl1vlz1rv4ibkvaqaq2g35-emacs-27.1 859.7   
> 106.2  12.4%
> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2132.8
> 53.2   6.2%
> /gnu/store/9lckq1194qcy4a7kv8bihagd58shj7yr-gtk+-3.24.20   723.7
> 49.0   5.7%
> /gnu/store/qizplwwgqwyq6qmz1i6jlaib5kgzrgwq-icu4c-66.1 110.2
> 38.1   4.4%
> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31  38.4
> 36.7   4.3%
> […]
> total: 859.7 MiB
> $ guix time-machine --commit=v1.3.0 -- size emacs 
> store item   totalself
> /gnu/store/g3idjpqsp2p2d163qfzskxj4k58nrx7f-llvm-11.0.0220.0   
> 148.6  16.9%
> /gnu/store/jf269s6clr6r57p8v5c3c1qkyra6apq2-mesa-20.2.4389.1   
> 141.6  16.1%
> /gnu/store/7nlq2v4000pw8vgj3m4vrwz072ib58xh-emacs-27.2 880.5   
> 106.4  12.1%
> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2132.8
> 53.2   6.0%
> /gnu/store/czf23hay13pp25yzrb4yq3n4gcri5r70-gtk+-3.24.24   744.3
> 49.1   5.6%
> /gnu/store/2wqjj3mkqdvsvksndr2hpjpi7qqwi7kr-icu4c-66.1 110.2
> 38.1   4.3%
> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31  38.4
> 36.7   4.2%
> […]
> total: 880.5 MiB
> $ guix time-machine --commit=v1.4.0 -- size emacs 
> store item   totalself
> /gnu/store/i11jmrc90drpx9mc6cyb6s4pjny91qx6-emacs-28.21592.7   
> 250.6  15.7%
> /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8411.6   
> 169.6  10.6%
> /gnu/store/6pdzpmxg5afzss6dlivq8z84sfa31x22-llvm-11.0.0221.5   
> 149.5   9.4%
> /gnu/store/lphzb1z0r4kbb453rsvnw7msrxxzp5r7-libgccjit-10.3.0   244.8   
> 128.5   8.1%
> /gnu/store/pfas3c4lhr1jwkj2gl0yx8dg4xjjlp4r-mozjs-91.13.0  261.2
> 65.4   4.1%
> /gnu/store/hy6abswwv4d89zp464fw52z65fkzr7h5-perl-5.34.0147.7
> 58.6   3.7%
> /gnu/store/zyqimpkmpffc24nwwqp46cicj8ss85y5-binutils-2.37  126.0
> 54.4   3.4%
> /gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7129.1
> 52.0   3.3%
> /gnu/store/4aq7hw017s9ihpm1rxpwfz28c80569z9-gtk+-3.24.30  1002.2
> 48.6   3.1%
> /gnu/store/vaxkf8cbc7slgc3ikm5qr3815wih93w8-ghostscript-with-cups-9.54.0   
> 219.139.1   2.5%
> /gnu/store/bjycxjjkp1da53ijsa4hfdrz9mcgg55h-icu4c-69.1 110.7
> 38.0   2.4%
> /gnu/store/ayc9r7162rphy4zjw8ch01pmyh214h82-glibc-2.33  76.6
> 36.6   2.3%
> […]
> total: 1592.7 MiB
>
> I think something went wrong here.  :-)
>
> In particular with Emacs itself (due to JIT + dependency on libgccjit,
> Binutils, etc.?) and with GTK+ (due to mozjs in polkit?).
>
> And then MESA and LLVM have always been problematically big.
>
> We should do better.  I mean, it’s just a text editor, isn’t it?
>
> Ludo’.
>

No, Emacs is more than a text editor.
If you need just a text editor, use ED.  ;)
But, well, I must confess, native compilation takes *A LOT* of time.

-- 
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib@hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."


signature.asc
Description: PGP signature

Re: Packages grow, no longer fit on a 

[Liliana Marie Prikler]

Am Samstag, dem 14.01.2023 um 23:07 +0100 schrieb Ludovic Courtès:
> Hello!
> 
> Over the course of a few years, the size of our packages has
> apparently kept growing.  Example:
> 
> --8<---cut here---start->8---
> $ guix time-machine --commit=v1.2.0 -- size emacs 
> store item  
> total    self
> /gnu/store/118xpdazyylxa1rlc68h9lmh38vhxrb4-llvm-10.0.0   
> 210.8   139.3  16.2%
> /gnu/store/1qmd9achfkm1njzxf8hi86q53pmy9sxk-mesa-20.0.7   
> 369.2   131.3  15.3%
> /gnu/store/d83hc7cqgnhl1vlz1rv4ibkvaqaq2g35-emacs-27.1
> 859.7   106.2  12.4%
> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2   
> 132.8    53.2   6.2%
> /gnu/store/9lckq1194qcy4a7kv8bihagd58shj7yr-gtk+-3.24.20  
> 723.7    49.0   5.7%
> /gnu/store/qizplwwgqwyq6qmz1i6jlaib5kgzrgwq-icu4c-66.1
> 110.2    38.1   4.4%
> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31 
> 38.4    36.7   4.3%
> […]
> total: 859.7 MiB
> $ guix time-machine --commit=v1.3.0 -- size emacs 
> store item  
> total    self
> /gnu/store/g3idjpqsp2p2d163qfzskxj4k58nrx7f-llvm-11.0.0   
> 220.0   148.6  16.9%
> /gnu/store/jf269s6clr6r57p8v5c3c1qkyra6apq2-mesa-20.2.4   
> 389.1   141.6  16.1%
> /gnu/store/7nlq2v4000pw8vgj3m4vrwz072ib58xh-emacs-27.2
> 880.5   106.4  12.1%
> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2   
> 132.8    53.2   6.0%
> /gnu/store/czf23hay13pp25yzrb4yq3n4gcri5r70-gtk+-3.24.24  
> 744.3    49.1   5.6%
> /gnu/store/2wqjj3mkqdvsvksndr2hpjpi7qqwi7kr-icu4c-66.1
> 110.2    38.1   4.3%
> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31 
> 38.4    36.7   4.2%
> […]
> total: 880.5 MiB
> $ guix time-machine --commit=v1.4.0 -- size emacs 
> store item  
> total    self
> /gnu/store/i11jmrc90drpx9mc6cyb6s4pjny91qx6-emacs-28.2   
> 1592.7   250.6  15.7%
> /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8   
> 411.6   169.6  10.6%
> /gnu/store/6pdzpmxg5afzss6dlivq8z84sfa31x22-llvm-11.0.0   
> 221.5   149.5   9.4%
> /gnu/store/lphzb1z0r4kbb453rsvnw7msrxxzp5r7-libgccjit-10.3.0  
> 244.8   128.5   8.1%
> /gnu/store/pfas3c4lhr1jwkj2gl0yx8dg4xjjlp4r-mozjs-91.13.0 
> 261.2    65.4   4.1%
> /gnu/store/hy6abswwv4d89zp464fw52z65fkzr7h5-perl-5.34.0   
> 147.7    58.6   3.7%
> /gnu/store/zyqimpkmpffc24nwwqp46cicj8ss85y5-binutils-2.37 
> 126.0    54.4   3.4%
> /gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7   
> 129.1    52.0   3.3%
> /gnu/store/4aq7hw017s9ihpm1rxpwfz28c80569z9-gtk+-3.24.30 
> 1002.2    48.6   3.1%
> /gnu/store/vaxkf8cbc7slgc3ikm5qr3815wih93w8-ghostscript-with-cups-
> 9.54.0   219.1    39.1   2.5%
> /gnu/store/bjycxjjkp1da53ijsa4hfdrz9mcgg55h-icu4c-69.1
> 110.7    38.0   2.4%
> /gnu/store/ayc9r7162rphy4zjw8ch01pmyh214h82-glibc-2.33 
> 76.6    36.6   2.3%
> […]
> total: 1592.7 MiB
> --8<---cut here---end--->8---
> 
> I think something went wrong here.  :-)
> 
> In particular with Emacs itself (due to JIT + dependency on
> libgccjit, Binutils, etc.?) and with GTK+ (due to mozjs in polkit?).
The effect is even more pronounced with emacs-minimal, as it
gratuitously pulls in libgccjit and binutils.  Compare

/gnu/store/lphzb1z0r4kbb453rsvnw7msrxxzp5r7-libgccjit-10.3.0   244.8   
128.5  27.2%
/gnu/store/wrzjr2g38f23fqg09rrdcn10va5gc5xl-emacs-minimal-28.2 472.4   
110.7  23.4%
/gnu/store/zyqimpkmpffc24nwwqp46cicj8ss85y5-binutils-2.37  126.0
54.4  11.5%
/gnu/store/ayc9r7162rphy4zjw8ch01pmyh214h82-glibc-2.33  76.6
36.6   7.8%
/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33  38.3
36.6   7.7%
/gnu/store/6d0pl5khj08j3c2619jnypc8bznspgx8-gcc-10.3.0-lib  71.7
33.4   7.1%
/gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib  71.7
33.4   7.1%
/gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32  91.6
16.4   3.5%
/gnu/store/9rrnm5hdjw7cy96a2a9rfgh6y08wsbmf-ncurses-6.2.2021061977.6 
5.9   1.3%
/gnu/store/pmq05n0q25v4qjyibxfrp53v4391k7vh-mpfr-4.1.0  78.4 
4.0   0.9%
/gnu/store/ajw8nnrnd6hr183skwqdgc8c7mazg97h-isl-0.2377.3 
2.9   0.6%
/gnu/store/fwbiihd2sbhai63y1pvvdh0f2bakfzrf-gmp-6.2.1   74.4 
2.7   0.6%
/gnu/store/4f304c7dp68hkcp1zi1i07zm8nfvvyp7-bash-static-5.1.81.7 
1.7   0.4%
/gnu/store/720rj90bch716isd8z7lcwrnvz28ap4y-bash-static-5.1.81.7 
1.7   0.4%
/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8  39.3 
1.0   0.2%
/gnu/store/xjwp2hsd9256icjjybfrmznppjicywf6-grep-3.673.5 
0.8   0.2%
/gnu/store/ba02g5xkqiss6s5z8mbj9cvkal6l7b9g-mpc-1.2.1   78.8  

Re: Packages grow, no longer fit on a 

[kiasoc5]

On 1/14/23 17:07, Ludovic Courtès wrote:

Hello!

Over the course of a few years, the size of our packages has apparently
kept growing.  Example:

--8<---cut here---start->8---
$ guix time-machine --commit=v1.2.0 -- size emacs
store item   totalself
/gnu/store/118xpdazyylxa1rlc68h9lmh38vhxrb4-llvm-10.0.0210.8   
139.3  16.2%
/gnu/store/1qmd9achfkm1njzxf8hi86q53pmy9sxk-mesa-20.0.7369.2   
131.3  15.3%
/gnu/store/d83hc7cqgnhl1vlz1rv4ibkvaqaq2g35-emacs-27.1 859.7   
106.2  12.4%
/gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2132.8
53.2   6.2%
/gnu/store/9lckq1194qcy4a7kv8bihagd58shj7yr-gtk+-3.24.20   723.7
49.0   5.7%
/gnu/store/qizplwwgqwyq6qmz1i6jlaib5kgzrgwq-icu4c-66.1 110.2
38.1   4.4%
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31  38.4
36.7   4.3%
[…]
total: 859.7 MiB
$ guix time-machine --commit=v1.3.0 -- size emacs
store item   totalself
/gnu/store/g3idjpqsp2p2d163qfzskxj4k58nrx7f-llvm-11.0.0220.0   
148.6  16.9%
/gnu/store/jf269s6clr6r57p8v5c3c1qkyra6apq2-mesa-20.2.4389.1   
141.6  16.1%
/gnu/store/7nlq2v4000pw8vgj3m4vrwz072ib58xh-emacs-27.2 880.5   
106.4  12.1%
/gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2132.8
53.2   6.0%
/gnu/store/czf23hay13pp25yzrb4yq3n4gcri5r70-gtk+-3.24.24   744.3
49.1   5.6%
/gnu/store/2wqjj3mkqdvsvksndr2hpjpi7qqwi7kr-icu4c-66.1 110.2
38.1   4.3%
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31  38.4
36.7   4.2%
[…]
total: 880.5 MiB
$ guix time-machine --commit=v1.4.0 -- size emacs
store item   totalself
/gnu/store/i11jmrc90drpx9mc6cyb6s4pjny91qx6-emacs-28.21592.7   
250.6  15.7%
/gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8411.6   
169.6  10.6%
/gnu/store/6pdzpmxg5afzss6dlivq8z84sfa31x22-llvm-11.0.0221.5   
149.5   9.4%
/gnu/store/lphzb1z0r4kbb453rsvnw7msrxxzp5r7-libgccjit-10.3.0   244.8   
128.5   8.1%
/gnu/store/pfas3c4lhr1jwkj2gl0yx8dg4xjjlp4r-mozjs-91.13.0  261.2
65.4   4.1%
/gnu/store/hy6abswwv4d89zp464fw52z65fkzr7h5-perl-5.34.0147.7
58.6   3.7%
/gnu/store/zyqimpkmpffc24nwwqp46cicj8ss85y5-binutils-2.37  126.0
54.4   3.4%
/gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7129.1
52.0   3.3%
/gnu/store/4aq7hw017s9ihpm1rxpwfz28c80569z9-gtk+-3.24.30  1002.2
48.6   3.1%
/gnu/store/vaxkf8cbc7slgc3ikm5qr3815wih93w8-ghostscript-with-cups-9.54.0   
219.139.1   2.5%
/gnu/store/bjycxjjkp1da53ijsa4hfdrz9mcgg55h-icu4c-69.1 110.7
38.0   2.4%
/gnu/store/ayc9r7162rphy4zjw8ch01pmyh214h82-glibc-2.33  76.6
36.6   2.3%
[…]
total: 1592.7 MiB
--8<---cut here---end--->8---

I think something went wrong here.  :-)


Maybe it is Emacs itself growing over time.


In particular with Emacs itself (due to JIT + dependency on libgccjit,
Binutils, etc.?) and with GTK+ (due to mozjs in polkit?).


If we look at emacs-next-pgtk, not only does it have JIT and PGTK, it 
also has xwidgets enabled, so it pulls in webkitgtk! Very big.



And then MESA and LLVM have always been problematically big.

We should do better.  I mean, it’s just a text editor, isn’t it?

It's an Lisp machine with a text editor! :)

We could have variants for building with the athena/motif toolkit so 
that we don't use GTK.