On Wed, Jul 16, 2014, at 19:28, Russ Allbery wrote: > Ondřej Surý <[email protected]> writes: > > On Mon, Jul 14, 2014, at 18:25, Jakub Wilk wrote: > > >> Food for thought: > >> Which fields take up most space in Packages.xz[0]? > > > 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 > metadata. > > 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 > today.
Ok, that makes much more sense now. Still is the main problem the download size or the size on the disk (I can guess that it can be a problem on embedded archs). Or both? Dropping md5+sha1 or even introducing sha-224 instead of sha-256 would help in this case. Having the fallback mechanism leaves open door for stripping+downgrade attacks anyway. Switching to an optimized binary format isn't an option? But I guess it won't be probably that much better than a good compression algorithm. O. -- Ondřej Surý <[email protected]> Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
