[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A plan for parameterized packages
From: |
Ludovic Courtès |
Subject: |
Re: A plan for parameterized packages |
Date: |
Fri, 20 Nov 2020 12:39:28 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
Hi,
Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> skribis:
> Last time I looked into how LibreCMC/OpenWRT did that, they had much
> more optimization than that. If I recall well, they use at least:
> - sstrip to strip binaries as much as they could. sstrip produces
> smaller binaries than with strip.
> - compilation flags like -Os
> - a read-only compressed filesystem with an overlay to store the
> changes
To me this looks like the ultimate size optimization level. Before we
get there, we should first see how to get closer to package sizes
typically found on Debian and that alone is a real challenge.
> The issue is that despite all that, the size of the images tend to
> increase too rapidly over time[1].
Yeah, that’s also the problem here: we have ‘guix size’ to profile a
package at one point in time, but it’s easy to unwillingly increase its
closure size the next day without noticing.
Chris: does the Data Service track store item sizes (and more generally
everything ‘query-path-info’ returns)? It’d be great to be able to
visualize size plots over time!
Ludo’.
- Re: A plan for parameterized packages, (continued)
- Re: A plan for parameterized packages, Taylan Kammer, 2020/11/15
- Re: A plan for parameterized packages, Danny Milosavljevic, 2020/11/15
- Re: A plan for parameterized packages, raingloom, 2020/11/15
- Re: A plan for parameterized packages, Denis 'GNUtoo' Carikli, 2020/11/19
- Re: A plan for parameterized packages,
Ludovic Courtès <=
- Re: A plan for parameterized packages, zimoun, 2020/11/20
- Re: A plan for parameterized packages, Christopher Baines, 2020/11/20
Re: A plan for parameterized packages, Ludovic Courtès, 2020/11/16
Re: A plan for parameterized packages, Stephen Christie, 2020/11/17