Le 02/05/2013 18:10, Matthias Klose a écrit : > no, I think the question here is how an xz compressed deb without using pack200 > looks like, compared to the size of today's packages. Is this just the gain you > would expect from switching from gzip to xz, or is this more? Ok, I conducted another test on xerces2.jar. The baseline is the gzip compressed jar as found in the .deb file. xalan2.jar 3290882 (+6.8%) xalan2.jar.gz 3079103 xalan2.jar.xz 2998300 (-2.6%) xz compression doesn't bring much in this case because the jar is already compressed. Here is the result with pack200: xalan2.jar.pack 2239001 xalan2.jar.pack.gz 896677 (-70.8%) xalan2.jar.pack.xz 760432 (-75.3%) Another test with rt.jar from the openjdk-6 package. This jar is not compressed unlike the other jar files in /usr/share/java. Unpacked: rt.jar 52170080 rt.jar.gz 17110391 rt.jar.xz 10561860 (-38.3%) Packed: rt.pack 13715998 rt.jar.pack.gz 5824549 (-65.9%) rt.jar.pack.xz 5065656 (-70.4%) xz is much more efficient in this case due to the uncompressed nature of rt.jar, but you still get a 50% improvement by throwing in pack200 compression. > so why is having smaller debs more critical? I don't claim this is critical, it's just a nice improvement. I wouldn't argue for a better compression if the expected gain was only 10% or 15%. But at 70% I think it's worth considering. > it breaks every package which assumes that openjdk is usable during upgrades, > partial upgrades, new installs, and so on. I'm not sure to understand. Do you mean that a Java application could be started at the same time openjdk is upgraded and should still function normally? How is this possible? Emmanuel Bourg
Attachment:
signature.asc
Description: OpenPGP digital signature