Summary: | app-arch/pigz[symlink] cause sys-libs/cracklib to fail in most of its tasks | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Gef <gef.kornflakes> |
Component: | [OLD] Core system | Assignee: | Dror Levin (RETIRED) <spatz> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | axiator, genzilla, hwoarang, jlec |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=888777 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 344103 |
Description
Gef
2010-06-18 21:15:33 UTC
Thanks for reporting this incompatibility. It seems to me that if pigz installs itself as a gzip replacement, it ought to be compatible with all the gzip options, and -d in particular is not even uncommon. So, I think this is a pigz bug, and will assign it accordingly... Somehow the problem is in this seious: emerge pigz[symlink] emerge cracklib passwd foo But solved here: emerge cracklib emerge pigz[symlink] passwd foo base-system, please prefix gzip with full path. no idea wtf you're talking about as the OP says, /usr/sbin/cracklib-format calls gzip without full path which breaks if pigz is emerge with USE=symlink. The best solution is calling gzip with full path. alternative is restricting the pigz to USE=-symlink during emerge of cracklib. so you want cracklib to execute /bin/gzip because some random package installs itself as `gzip` and breaks other random packages ? that isnt going to happen. app-arch/pigz[symlink] doesnt make any sense. remove it. Just came across this bug myself. Why is app-arch/pigz-2.16[symlink] still in stable when installing it breaks portage for any file where the source is *.gz (including itself and gzip)? (In reply to comment #7) > Just came across this bug myself. Why is app-arch/pigz-2.16[symlink] still in > stable when installing it breaks portage for any file where the source is *.gz > (including itself and gzip)? > For me it woks well for nomal portage operations. Only the cracklib thiing is bad. This happens because during that operation gzip is take from /us/bin and not fom /bin, whihc results in the use of pigz and not gzip (In reply to comment #8) > (In reply to comment #7) > > Just came across this bug myself. Why is app-arch/pigz-2.16[symlink] still in > > stable when installing it breaks portage for any file where the source is *.gz > > (including itself and gzip)? > > > > For me it woks well for nomal portage operations. Only the cracklib thiing is > bad. This happens because during that operation gzip is take from /us/bin and > not fom /bin, whihc results in the use of pigz and not gzip Again encoutered this bug with cracklib, without having any other problem with portage or other package. Is there any move gentoo side, or has pigz-mainstream been advised of this gzip compliance fail? This is fixed in pigz-2.1.6-r1, see bug #335852. I suggest stabilizing pigz-2.1.6-r1, it has been a while since it was introduced. # echo aa | pigz -c > aa.gz # pigz -cd aa.gz aa Although the issue here seems to be with the suffix - that's not fixed yet in unstable pigz (see my suggestion in the bug above). This should be fixed with pigz-2.1.7. Please test and reopen if needed. Thanks. |