Re: Let's shrink Packages.xz
On Wed, Jul 16, 2014, at 19:28, Russ Allbery wrote:
> Ondřej Surý <email@example.com> writes:
> > On Mon, Jul 14, 2014, at 18:25, Jakub Wilk wrote:
> >> Food for thought:
> >> Which fields take up most space in Packages.xz?
> > I am still lost - what problem are we trying to solve here?
> > Could we at least define it to see if the problem exists?
> I'm fairly sure Jakub's message was in response to the recent discussion
> about small Node.js packages and the frequent complaints that we should
> not introduce small packages into the archive because it bloats our
> Reducing the size of Packages.xz by 11% or 22% would leave room for quite
> a lot of small packages while not making the problem any worse than it is
Ok, that makes much more sense now. Still is the main problem the
size or the size on the disk (I can guess that it can be a problem on
archs). Or both?
Dropping md5+sha1 or even introducing sha-224 instead of sha-256 would
in this case.
Having the fallback mechanism leaves open door for stripping+downgrade
Switching to an optimized binary format isn't an option? But I guess it
be probably that much better than a good compression algorithm.
Ondřej Surý <firstname.lastname@example.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server