Summary: | ebuild fails on certain combinations of options | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Joshua Kinard <kumba> |
Component: | Unclassified | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | kumba |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Joshua Kinard
![]() This one is a little weird... What're you FEATURES flags? Just post 'emerge -v info' I tested this on sparc64 and x86, and got "tseng" in #gentoo-dev to confirm it. Sparc64 box: FEATURES="-sandbox ccache manifest strict" (-sandbox because sparc64 uses -fstack-protector) x86 box: FEATURES="sandbox ccache manifest strict" i did this just now: `ebuild <ebuild> clean unpack` then i went in and did the compile stage myself `ebuild <ebuild> install` `ebuild <ebuild> qmerge` and it failed with depend output ... looking in /var/tmp/portage/<pkg>/ i found i was missing build-info ... when i did `mkdir` on that dir (i didnt bother populating it with files), the qmerge worked ... it complained about the ebuild not being in build-info, but at least it put the files on my / :) Gonna shut this bug of mine out as invalid. From what I can tell, qmerge just lacks some basic error checking. In order to execute the "qmerge" option, the unpack, compile, and install phases have to be complete. Having qmerge do all those for you (like install does unpack & compile first) is just redundant as this is what the "merge" command does. The real fix for this is to have qmerge see if unpack or compile as been done first, and if not, yell at the user, but it's extremely trivial and not really important, so it can just be closed. |