Am 01.05.2013 22:00, schrieb Emmanuel Bourg: > Le 01/05/2013 20:33, Matthias Klose a écrit : > >> thanks for checking. I assume that xz or bz2 compression won't help there >> either? > > pack200+xz/lzma is slightly better than pack200+gz, but not much (~3% > for my example with libcommons-jexl2-java). pack200+bzip2 wasn't better > than pack200+gz.
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? >> otoh not having the hashsums is a substantial loss. > > Well, even with packed jar files the checksums are still useful to check > the integrity of the package at install time. But the integrity of the > jar files can't be checked after the installation. If this is a critical > point we can find another way to do it, like recording somewhere the > checksums of the generated files. so why is having smaller debs more critical? >> no way. Having the interpreter/runtime only available after configure time, >> and not just after unpack time makes the installation of packages more >> complex >> and does break upgrades in some ways. Just look back at the python-support >> and python-central times when these symlinks were created at configure time. >> Today the only thing which is done for python packages at configure time is >> to >> byte compile .py files, which is an optimization only. The packages are >> usable >> without it as well. > > How could unpacking rt.jar in the postinst script break the installation > or the upgrade? That seems pretty simple though, I'm not sure to understand. it breaks every package which assumes that openjdk is usable during upgrades, partial upgrades, new installs, and so on. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5182900d.4090...@debian.org
