see the output of the following command: cd $( portageq envvar PORTDIR ) ; ls sys-devel/*-config/files/*-config-* | xargs grep -C2 -n --color=yes '\[\[ \${ROOT} != /\* \]\] && ROOT="\${PWD}\${ROOT}"' i.e.: sys-devel/gcc-config/files/gcc-config-1.5.1-10-: ${ROOT:=/} sys-devel/gcc-config/files/gcc-config-1.5.1-11-[[ ${ROOT} != */ ]] && ROOT="${ROOT}/" sys-devel/gcc-config/files/gcc-config-1.5.1:12:[[ ${ROOT} != /* ]] && ROOT="${PWD}${ROOT}" sys-devel/gcc-config/files/gcc-config-1.5.1-13- sys-devel/gcc-config/files/gcc-config-1.5.1-14-cd / "You keep using that word... I do not think it means what you think it means..." As a reminder, ${PWD} in bash looks like: /usr/portage so if ${ROOT} doesn't match the shell glob "/*" (without the quotes), then ${PWD}${ROOT} contains two directory names concatenated together. What this really means is that nobody uses or needs the PWD-fallback feature this code is trying to implement -- if someone was using it, their gcc-config would have gone batshit-crazy and they would have made a bunch of noise about it. Instead, {gcc,binutils}-config should die if ${ROOT} does not start with a slash (this would not apply the empty ROOT/unassigned ROOT cases, due to the preceeding statement -- although note that in prefix binutils that statement is commented out for some reason (!?)) Actually, one could argue that by (almost always) causing a crash/failure, the current behavior is better than the intended behavior -- I just don't see relative ${ROOT} support as a desirable portage feature at all, especially in a script that is going to shuffle around a bunch of core libraries as root without any protection against collisions with portage-owned files (or anything else, for that matter). Reproducible: Always Steps to Reproduce: not even going to type them here, but there are definitely ways to wreck your system with this
i don't see your point. "garbage in, garbage out". if you don't like the relative-ROOT behavior, then stop setting your ROOT value to a broken setting ?
(In reply to comment #1) > i don't see your point. "garbage in, garbage out". if you don't like the > relative-ROOT behavior, then stop setting your ROOT value to a broken > setting ? There's room for philosophical disagreement as to whether relative-ROOT is a good idea -- but this is not a GIGO bug. Maybe I should have included steps to reproduce so I will do so now. Let's create a fake ENV_D for gcc-config to fail on: try: cd /somewhere/harmless mkdir -p testing123/etc/env.d cp -av $(portageq envvar EPREFIX)/etc/env.d/gcc testing123/ No need to fix up the paths in those config-${TARGET} files, gcc-config will never find them: ROOT=testing123 gcc-config -l the results will always be: * gcc-config: No gcc profile is active! Using gcc-config info in /somewhere/harmlesstesting123/[EPREFIX]/usr/bin/gcc-config: line 83: /somewhere/harmlesstesting123/[EPREFIX]/etc/env.d/gcc/config-[CHOST]: No such file or directory where [EPREFIX] is replaced by $(portageq envvar EPREFIX) and [CHOST] is replaced with $(portageq envvar CHOST). Note specifically that we never created a /somewhere/harmlesstesting123 -- we created /somewhere/harmless/testing123. Similar results will occur with binutils-config Put another way, the following patch should be applied to each of the files listed by: cd $( portageq envvar PORTDIR ) ; ls sys-devel/*-config/files/*-config-* --- files/foo-config-ver.orig 2012-08-13 09:59:17.818350000 -0700 +++ files/foo-config-ver 2012-08-13 09:59:32.789350000 -0700 @@ -12 +12 @@ -[[ ${ROOT} != /* ]] && ROOT="${PWD}${ROOT}" +[[ ${ROOT} != /* ]] && ROOT="${PWD}/${ROOT}" (but, with foo replaced with binutils or gcc and ver replaced with various version suffixes, as appropriate).
(In reply to comment #2) > (In reply to comment #1) > mkdir -p testing123/etc/env.d > cp -av $(portageq envvar EPREFIX)/etc/env.d/gcc testing123/ oops, should read: mkdir -p testing123/$(portageq envvar EPREFIX)/etc/env.d cp -av $(portageq envvar EPREFIX)/etc/env.d/gcc testing123/$(portageq envvar EPREFIX)/etc/env.d but as you can see it's not going to make any difference.
I suppose I have created a bit of a muddle by ranting against relative-ROOT in my bug. Really, I guess I've reported two "bugs" here: o A very clear code bug in the various -config scripts which has existed since the first check-on o A suggestion that the feature in question is probably not being used by anyone (since this bug has been there from the get-go and nobody seemed to notice), and that, even if we fixed it, it might not be a very stable or useful feature. The first bug is just a simple coding error. Add the slash and it's fixed. the second bug probably shouldn't be fixed without some kind of discussion. If someone is using this feature, they should clearly have the opportunity to explain why they find it helpful. If we just remove relative-ROOT support from gcc-config it probably will still exist in numerous other places: $ cd /tmp $ portageq envvar EPREFIX /g2pfx $ mkdir foo $ ROOT=foo portageq envvar EROOT /tmp/foo/g2pfx/ which would create a bunch of cruft in portage and probably elsewhere as well. So if we want to remove relative-root -- I kinda think we do, but reasonable people could certainly disagree -- it shouldn't just be done for gcc-config in response to this bug. It should be done in numerous places all at once, so that portage can behave consistently, and the various tools can politely warn anyone who may have used this feature in the past that it is no longer supported. I think, this bug is the wrong place for this discussion, so I'm going to say, let's fix the missing "/", close this bug, and I can float the more complicated/interesting question about whether or not to keep relative-ROOT support on the mailing list.
Created attachment 321242 [details] script to fix missing slashes en-masse This script will fix the missing slashes en-mass (I know of at least three trees that need fixing :P) Accepts a list of portage tree directories, i.e., /usr/portage -- will use the ones your portage knows about if no defaults provided.
Created attachment 321244 [details] Fix missing slashes in foo-config scripts
Comment on attachment 321244 [details] Fix missing slashes in foo-config scripts fixes bug in previous attempt. This script will fix the missing slashes en-mass (I know of at least three trees that need fixing :P) Accepts a list of portage tree directories, i.e., /usr/portage -- will use the ones your portage knows about if no defaults provided.
Comment on attachment 321244 [details] Fix missing slashes in foo-config scripts (In reply to comment #2) the point was that i'm disabling relative-ROOT because you don't like or use it. i do, and seeing as how i use it and am the author, i guess it stays. this script isn't useful.
looks like i broke it between gcc-config 1.4.1 and 1.5 in one of the big rewrites, most likely imported from binutils-config should be fixed: http://git.overlays.gentoo.org/gitweb/?p=proj/gcc-config.git;a=commitdiff;h=7f30cd15401b7c9d22af0690ee03f2c40415b502 http://sources.gentoo.org/sys-devel/binutils-config/files/binutils-config-3?r1=1.8&r2=1.9
