| Summary: | portage should allow configuration of bzip2/bunzip2 commands for calling pbzip2 | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Zac Medico <zmedico> |
| Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | drizzt, esigra, rain |
| Priority: | High | Keywords: | InVCS |
| Version: | 2.1 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 335925 | ||
| Attachments: | Squashed and cleaned 2.1 backport | ||
|
Description
Zac Medico
2010-08-31 00:17:19 UTC
PORTAGE_BUNZIP2_COMMAND is provided for flexibility, but if it's unset then we can fall back to $PORTAGE_BZIP2_COMMAND -d. Support for binary packages is here: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=50daef1ab961c42a3352281e915da5a89297e3a9 ebuild.sh support is here: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=26e57cd28c43074b4eca54fb11ee1ab3497a1530 Note: ecompress and ecompressdir don't have support for this because they already have separate PORTAGE_COMPRESS and PORTAGE_COMPRESS_FLAGS configuration variables. I think it makes most sense for binary packages only anyway. And if it allows the override of unpacking the upstream tar.bz2 tarballs using the parallel uncompress, even better. Maybe two variables for GZIP would close the chain, i hear there's also a parallel implementation of gzip (pigz), so that people obsessed with parallelism can make use of the most of their computers. This is fixed in 2.2_rc73, but I'll leave this bug open until it's fixed in an unmasked version. Created attachment 245771 [details, diff]
Squashed and cleaned 2.1 backport
I've ported/cleaned up a patch that works for me and seems to do the right thing in 2.1.7.17 (the one chromeOS uses), which I'm experimentally epatching to our portage.
I ran into issues where portage, when upgrading cuts its own branch under itself.
While enviroment is preserved correctly in the python, right after install phase, when emerge preserves the enviroment into enviroment.bz2, this fails because the new ebuild.sh is used, but old make.globals are still sourced.
This technically works, but breaks the enviroment in package database and produces a backtrace.
What we did is basically S/${PORTAGE_BZIP2_COMMAND}/${PORTAGE_BZIP2_COMMAND:-bzip2}, in all places. That means that in addition to make.globals setting a default, there's a fail-safe last resort default for all instances of the variable. I'm not sure if the same is a problem for the 2.2 portage patch.
(In reply to comment #7) > What we did is basically > S/${PORTAGE_BZIP2_COMMAND}/${PORTAGE_BZIP2_COMMAND:-bzip2}, in all places. I already had something like that here: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=9437c8071af071ebd753c4ed29ce53948dcb9b1e There's also related commits here: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=75dab994c4a3e7c38ea29cc633706c435991da05 http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=c050d9441afa4523c1a7a5341e3daae90e4c2a4e This is fixed in 2.1.9. Thanks! Also, note that there is a bug open for something similar, which you probably might want to close too: http://bugs.gentoo.org/show_bug.cgi?id=264258 What should noted, that pbzip2 (the reason for this bug) is having slight trouble with the abuse that portage is giving it, in particular attaching bzipped garbage at the end of the binary packages. I have a patch to at least make it stop failing, and beyond that, it seems to have no impact except for some of the unbzipped files being slightly larger (but tar seems to ignore that part). I'll investigate in more detail, and try to push the patches upstream to make it work 100% with portage. Other than that, pbzip seems to be an entirely drop-in replacement, because it even supports identical options, and since v1.1.1 does not seem to face bunzip regression when switching from pbzip to bzip and back. *** Bug 264258 has been marked as a duplicate of this bug. *** |