| Summary: | emerge -k libperl fails to use the packaged tarball | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Bel Zébute <stephane> |
| Component: | New packages | Assignee: | Gentoo Perl team <perl> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | minor | CC: | dev-portage |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Bel Zébute
2004-12-20 14:44:44 UTC
Can you provide example output and ls packages/*perl* ? I won't provide an example output, but you can easily verify this yourself. Enable the buildpkg in FEATURES, emerge once to create the tarball package, re-emerging with the -k switch should use that tarball package, but it does not. Maybe it's Portage, I don't know. All I know is that I have to emerge libperl sequentialy on all the nodes, because the tarball is recreated each time, and eventualy a node will untar whiel another is taring and BOOM!. # emerge -kvp libperl | grep binary [binary R ] sys-devel/libperl-5.8.6 +berkdb -debug -gdbm -ithreads (-uclibc) Please provide the output as Nick asked... I have just encounter the same problem with binutils. So maybe it's more a limitation with Make, distcc or the like. With MAKEOPTS=j32, biutils failed. I then lowered it to -j24 and specified the IPs in /etc/distcc/hosts one by one treee time each (instead of IP/3), but still failed. It worked when I did MAKEOPTS-j3 emerge binutils. So I guess I could recompile again and again, incrementing MAKEOPTS by 1 each time to find the upper limit. My point is that there seem to be such a limit, but I don't know what modulates that, because most of the packages builds fine and parallelize well. Oups! Man :( Wrong bug. I'm sorry. This has nothing to do with the bug mentionned about libperl, which is that emerge -k libperl wont use the buildpkg version and instead compile from scratch. I'm so sorry :( |