Summary: | euse sources /etc/make.conf | ||
---|---|---|---|
Product: | Portage Development | Reporter: | guillaume <guillaume.ramelet> |
Component: | Tools | Assignee: | Portage Tools Team <tools-portage> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | jakub |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
guillaume
2005-08-05 03:21:10 UTC
Well, is does not fail for me, and enotice is a portage hack which is in no way supported anyway. Closing. This can be seen without enotice as well. euse assumes that you can just source /etc/make.conf. You can't anymore. A way of seeing this is by changing USE="..." to USE = "..." in your make.conf. The file will still be valid, portage will still work the same way, but euse will not work correctly with it. Or, if your portage tree is not in /usr/portage, change PORTDIR="..." to PORTDIR = "...", and euse won't work at all. (In reply to comment #2) > This can be seen without enotice as well. euse assumes that you can just source > /etc/make.conf. You can't anymore. Uhm, maybe we should first define what is a valid syntax when make.conf is concerned. This works just fine if you don't put superfluous spaces in there. Also see Bug 100373 and Bug 101486. (In reply to comment #3) > Uhm, maybe we should first define what is a valid syntax when make.conf is > concerned. Agreed, and the meaning of that syntax should also be clearly described. You get subtle differences if make.conf does VAR2="${VAR1} ...", but the setting of VAR1 is commented out at the moment. With portage, "${VAR1}" will be "". With sourcing, VAR1 will be read from the environment. > This works just fine if you don't put superfluous spaces in there. A="B"C="D". Portage reads it as two assignments (A="B" C="D"). bash reads it as one (A="BC=D"). The extra space is necessary here if you want to source it correctly. (This is really a portage bug that's supposed to be fixed with 2.1 but for the 2.0 series, this won't be changed.) > Also see Bug 100373 and Bug 101486. Yup, a clear description of the file format would be very useful. (In reply to comment #4) > subtle differences if make.conf does VAR2="${VAR1} ...", but the setting of VAR1 > is commented out at the moment. With portage, "${VAR1}" will be "". With > sourcing, VAR1 will be read from the environment. Heh, I did hit that one in Bug 94850. > A="B"C="D". Portage reads it as two assignments (A="B" C="D"). bash reads it as > one (A="BC=D"). The extra space is necessary here if you want to source it > correctly. (This is really a portage bug that's supposed to be fixed with 2.1 > but for the 2.0 series, this won't be changed.) Just to add, these superfluous/double/multiple spaces break a couple of ebuilds as well when they are in C[XX]FLAGS - just search bugzilla for 'ALL flags changed'. That should be solved on portage level as well, IMHO. I believe the consensus from gentoo-portage-dev ML was that /etc/make.conf should be bash sourceable, and anything not bash sourceable was in fact an invalid make.conf file. I know Brian is working on the parsing for the portage rewrite to be as close to bash syntax as he can make it so that no functionality is lost. However in this case the user would need to modify their make.conf to be sourceable by bash. Applications may depend on that assumption ( which euse does ). |