Hello, I think we could use the lzma compression instead of bzip2 by adapting the compression level to the memory host. Basically, we can detect the memory host by the package which is being emerged. For example, emerging OpenOffice should tell portage that it can use up to 40 MB for uncompressing and thus compress the package with the higher rate. On the other side, generic packages like kernels, shells, etc should use smaller footprints equivalent to bzip2 but with a higher compression rate. See the memory footprints and compression rates: http://tukaani.org/lzma/benchmarks Reproducible: Always
or we just add an option for the compressor and flags like ECOMPRESS and let the user decide
I mean we could use a meta information of the package which tells the minimum memory needed for running the provided programs. Then the package builder would use this information in order to automatically select the default compression strategy and level: - < 4MB: gzip --best - up to 4MB: bzip2 --best - up to 8MB: lzma --level ~5 - up to 16MB: lzma --level ~6 - up to 32MB: lzma --level ~7 - up to 64MB: lzma --level ~8 - up to 128MB: lzma --level max
In the master branch, we now have support to configure binary package compression with BINPKG_COMPRESSION and BINPKG_COMPRESSION_ARGS variables: https://gitweb.gentoo.org/proj/portage.git/commit/?id=cff2c0149142843316e1851c2e73bcec30f08471
(In reply to Zac Medico from comment #3) > In the master branch, we now have support to configure binary package > compression with BINPKG_COMPRESSION and BINPKG_COMPRESSION_ARGS variables: > > https://gitweb.gentoo.org/proj/portage.git/commit/ > ?id=cff2c0149142843316e1851c2e73bcec30f08471 I think this is therefore fixed.
