Re: Pack200 compression of packaged jars
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.
Reply to: