I noticed some strange results with the USE flags in ufed and also in general. Now I have to begin with telling thta I don't know exactly how the final USE variable is calculated, but I guessed that USE_ORDER="env:conf:auto:defaults" .. in /etc/make.globals would define the order to be (higher in list overrides those below): 1. environment variable "USE" (in my case not set) 2. /etc/make.conf 3. /etc/make.profile/use.defaults (portage.py mentioned this file under "autovars" or alike) 4. /etc/make.profile/make.defaults I did some study and I present here only the entries I considered buggy. It's possible and even probable that my tests don't reveal all peculiar behaviour, but here's what I found. I hope the data I provide can help you in fixing the possible problems. I considered the "USE" file of an installed package to be a proper measurement of what flags were active during the compilation of an ebuild, i.e. for example /var/db/pkg/app-admin/ufed-0.2/USE. If this is not the case, then it might as well be that some or all of my conclusions are invalid. Of course, I might be totally off track anyway =) -- First of all, it seems like ufed doesn't look at use.defaults at all, and considers only flags enabled in make.defaults to be "on" by default. As a motivation to my statement: For all flags enabled in use.defaults, the flag was listed in make.conf *only* when also selected through ufed, and not the other way around which I thought should be the case (i.e. unselected flags should be present as "-bonobo" in make.conf, and selected flags absent, for all flags present in use.flags, like is done for all flags present in make.defaults). Secondly, the resulting USE file lacked some flags enabled by use.defaults and not touched by make.conf or make.defaults. All flags that were present in either make.defaults or make.conf successfully made it to the resulting USE file. The flags that for me were listed in use.defaults but *not* in the resulting USE file were: aalib alsa directfb ggi mozilla postgres scanner snmp Flags that were listed in use.defaults *and* in the resulting USE file, as expected: bonobo esd guile tcltk Maybe there's a file somewhere that I don't know of that adjusts the aalib, alsa etc flags that didn't appear in the resulting USE file.. If not, then is there maybe a bug in portage or somewhere else? -- If you need more info, or help testing or analyzing, or just don't understand a word that I'm saying, please don't hesitate contact me. - xkr47 @ {freenode,ircnet,quakenet}
`man make.conf` to see how USE_ORDER works
some other (what I think is) strange behaviour I just typed ufed (after backing up my make.conf ;)) and i checked if everything was working fine. I saw that cups and arts and gnome (and some other) where selected although i I put a '-*' and no arts in my make.conf. my USE before ufed: USE="-* 3dnow aalib alsa avi crypt dga encode gif gtk imlib ipv6 java jpeg kde lcms mikmod mmx motif mozilla mpeg ncurses oggvorbis opengl pam pdflib perl png python qt qtmt quicktime readline sdl spell sse ssl svga tcltk tcpd tiff truetype wmf X xml xml2 xmms xv" my USE after ufed (quit and save after starting it up) USE="aalib alsa dga ipv6 lcms mozilla perl sse tcltk tiff wmf xml" pretty scarry :/ emerge -up --deep world wants to compile 51 programs instead of 2.
maybe there should be a 'X' '-' and 'blanco' option ? and some of the options explanations are to long and therefor I can't read it :) maybe a '?' on some of them ?
I don't know if I'll get to this by the end of the package upgrade phase on sunday, but it is in the todo list (I have finals shortly so that's my delay).
the use.defaults part is fixed. the strange behaviour _should_ be fixed. please test ufed 0.3 in unstable and re-open the bug if the strange behaviour problem isn't resolved totally and it the docs don't resolve it. please test your '-*' esp, i'm not certain on that at the moment.
Tested ufed 0.3 and I can confirm that it worked correctly now for me.. except for the gif/ungif bug #20204 I posted earlier today, but that is a different bug, so it seems to me this bug has been fixed now.
Closing bug properly.
closing bug again.
