Bug 307625 – app-portage/portage-utils fails to read nested variables from make.conf

• Status: RESOLVED WORKSFORME
• Product: Portage Development

[Description Wilke Schwiedop 2010-03-03 15:14:48 UTC]

While valid in portage, portage-utils cannot read variables if they contain a variable themselves.

Example:
portage_basedir="/usr/portage/"
PORTDIR="${portage_basedir}/ebuilds"

This configuration breaks most q-applets.

Reproducible: Always

Steps to Reproduce:
1. Set PORTDIR variable as shown in the example
2. run 'qsearch vim'

Actual Results:  
q: chdir into PORTDIR '${portage_basedir}/ebuilds' failed: No such file or directory

[Comment 1 solar (RETIRED) 2010-04-02 02:14:23 UTC]

This is expected behavior in portage-utils as the make.conf is parsed in c vs being sourced in bash.

[Comment 2 SpanKY 2011-12-18 03:05:22 UTC]

this is somewhat fixed.  we now expand variables we know about.  so if you have:
  EPREFIX=''
  PORTDIR='${EPREFIX}/usr/portage'
  PKGDIR='${PORTDIR}/packages'
things will get expanded accordingly ... i don't think we'll move beyond that as in your example:
  portage_basedir="/usr/portage/"
  PORTDIR="${portage_basedir}/ebuilds"

as solar said, that'd require tracking all variables which we just don't care

http://sources.gentoo.org/gentoo-projects/portage-utils/main.c?r1=1.200&r2=1.201

[Comment 3 SpanKY 2011-12-19 22:49:53 UTC]

*** Bug 395315 has been marked as a duplicate of this bug. ***