Summary: | FEATURES="noauto" ebuild <ebuild> clean setup unpack causes ${A} not to be set | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Petteri Räty (RETIRED) <betelgeuse> |
Component: | Core - Ebuild Support | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 108082 | ||
Attachments: | ebuild.sh.patch |
Description
Petteri Räty (RETIRED)
2005-10-01 04:08:38 UTC
as this doesn't seem to be in the tree, please attach the actual ebuild, otherwise we have to guess too much. It'll trigger on FEATURES="noauto"ebuild $PORTDIR/dev-util/diffball/diffball-0.6.5.ebuild clean setup unpack I'm kind of inclined to just state noauto is broke and be on my merry way... with noauto off, this is fixed in p.masked 2.0.53, horked in <.53 (In reply to comment #2) > I'm kind of inclined to just state noauto is broke and be on my merry way... > with noauto off, this is fixed in p.masked 2.0.53, horked in <.53 If we go the way of stating noauto being broken/unsupported, we should make all the documentation reflect this. i also really hate taking that stance FEATURES=noauto is invaluable to developers It's not really broken. It just requires expert knowledge. This bug is either INVALID or can only be fixed by reordering specified phases and hence removing power/flexibility. i dont really see how `ebuild <ebuild> clean setup unpack ...` is using it wrong You're assuming "clean" and "setup" should be independent of each other. This is a natural assumption, which I'd also make the mistake of making. However, `ebuild <ebuild> setup` does more than just run pkg_setup, which is where expert knowledge comes into it. Having said that, I had a quick look at the code and can't see why ${A} isn't being passed down to the ebuild env. I think it would be best to add loud warnings if people try to run functions out of order and be done with it. Created attachment 69851 [details, diff]
ebuild.sh.patch
Don't set A (via declare -r) if it's unset.
Comment on attachment 69851 [details, diff] ebuild.sh.patch >Index: bin/ebuild.sh >=================================================================== >--- bin/ebuild.sh (revision 2082) >+++ bin/ebuild.sh (working copy) >@@ -1733,8 +1733,10 @@ > > unset E_IUSE E_DEPEND E_RDEPEND E_CDEPEND E_PDEPEND > >-declare -r T P PN PV PVR PR A D EBUILD EMERGE_FROM O PPID FILESDIR >-declare -r PORTAGE_TMPDIR >+for x in T P PN PV PVR PR A D EBUILD EMERGE_FROM O PPID FILESDIR PORTAGE_TMPDIR; do >+ [[ ${!x-UNSET_VAR} != UNSET_VAR ]] && declare -r ${x} >+done >+unset x > > # Turn of extended glob matching so that g++ doesn't get incorrectly matched. > shopt -u extglob Note the difference between declare -r ${!x} and declare -r ${x} :) Fixed in portage-2.0.53_rc4 |