For the reasons exposed in the above URL, I would like to be able to specify a "${PORTDIR}/something" path in the parent file of a profile I distribute. I will attach a patch which makes that possible. Changes are: - to support absolute paths, use os.path.join() for paths concatenation instead of a string operation - to evaluate the ${PORTDIR} variable, use portage_util.varexpand() - to get the PORTDIR value soon enough, read /etc/make.{globals,conf} before stacking the profiles. It means that: - portage won't read "make.globals" from profiles anymore (wheras that was the case with existing code, despite it was not documented, and probably not useful since there is make.default for this purpose) - the profiles list may be wrong if someone redefines PORTDIR in a "make.defaults" file (but that sounds like a bad idea anyway - should the doc mention it, or maybe a check against a blacklist of vars that should not be modified there?) - other minor stuffs: a warning for parent files with non-existing target, and for parent files that create loops (i made one by mistake while playing with my profiles, and it live-locked very well :)) Reproducible: Always Steps to Reproduce:
Created attachment 52329 [details, diff] 2.0.51.17-portage.py-absolute_parent_paths_in_profiles.patch
Created attachment 53511 [details, diff] 20050313--absolute_parent_paths_in_profiles.patch Same patch as above, but for HEAD. I still hope that's something that could go in .51 tho :)
Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;)
Reopening since this one has its patch, and since i think it's something simple but very important (that really solves a blocking issue for distribution of customized gentoo profiles). Note that this patch is against an old HEAD tho, not Brian's rewrite (i've not had time to look at this version yet).
Absolute paths are possible, not sure if I like the $PORTDIR idea or not.
While I see the use for this I really don't like the special case this would implement regarding evaluation order (as in theory PORTDIR might very well depend on make.defaults variables, even if that's extremely unlikely to happen when this feature is used as well I'd rather not open that box in the first place), therefore I'm closing this.
(In reply to comment #5) > Absolute paths are possible, not sure if I like the $PORTDIR idea or not. This is one of the cases where os.path.join() actually does what we want when given an absolute path as the second argument. Since we use this function to join the paths, it's okay to use absolute paths in the parent file.
