[Solved]circular dependencies when emerging wpa_supplicant

[picarones]

Hi - I'm trying to install Gentoo for the first time (really, the second time, the first time I gave up at this exact point). The machine is a Samsung np300e5e laptop.

[Hu]

Disable USE=gtk-doc, at least for now. You say you accepted the proposed changes and got a new round of errors, but you did not show the round of errors at which you gave up. Please show them.

[picarones]

Thanks for your reply. I removed gtk-doc from USE in my make.conf:

[picarones]

BTW, is there some way to get the text within the code tags to wrap?
Or should I use a different tag for command output?

[Hu]

Remove USE=libressl. When it is enabled, you choose libressl for packages that support it. This is fine if you use only packages that support it. For a new user / new install, start with openssl, get a working environment, and then you can explore switching to libressl.

[picarones]

That seems to have done it - wpa_supplicant emerged successfully - thank you so much.

A couple of additional questions, if I may:

1. I would like to re-add qt5 and gtk-doc to the USE variable. Is that advisable? In other words, is it possible to tell whether the problem was only libressl all along or whether qt5 and gtk-doc were actually problematic as well?

2. What about the modified zz-autounmask file? Should I leave that as it is, or should I restore its original content?

3. More broadly, is trial and error the only way to determine whether a USE variable flag is compatible with a particular package? I am aware that the use.desc file has some warnings in it, but none that refer to libressl, qt5, or gtk-doc.

Again, thank you very much for your help.

[Hu]

1. USE=doc (which is different from USE=gtk-doc) is often advised to be set only on the packages where you specifically need it, since it often causes extra dependencies. The situation may (or may not) be the same with USE=gtk-doc. Enabling USE=qt5 globally is probably fine. At worst, you will get a conflict like the one we solved here, and you can work through it or reverse the change. You may want to read about and make more use of package.use, so that you can selectively enable these flags on packages where you need them, without having them enabled on packages where you don't need them.
2. I would remove as many changes as you can remove without causing the system configuration to deviate from what you think you want. Remove redundant entries, and any flags that set options you don't care about. As above, you can't cause serious problems with a mistake here, so feel free to experiment. You might want to comment out, rather than delete, flags in these files. Then if you decide that disabling it was a mistake, you can remove the comment marker to reactivate it.
3. You had a rough introduction to the USE system, by enabling some flags that have significant effects. You can inspect an ebuild's dependency data, or the output of emerge --pretend --verbose with particular flags set, to see how big an impact a USE change will have. In the general case, there is no good way to predict which flags will trigger massive dependency trees, but if you use --pretend and examine the tree before you let Portage proceed, you can abandon difficult paths before doing anything hard to reverse.
   • USE=libressl tries to switch packages over to an alternate library that cannot be co-installed with openssl, so it is an all-or-nothing switch. The main tree only supports this if you are willing to exclude some packages that have not switched yet. (Some of these packages may have libressl-compatible variants in overlays, if you want libressl as soon as possible.)
   • USE=qt5 will usually cause a dependency on Qt packages, which are large and may have many dependencies of their own. Once the system is bootstrapped and has all the required Qt libraries installed, enabling qt5 will likely be easier.
   • As noted above, enabling documentation tends to cause lots of extra dependencies. Most USE flags have less impact.

[picarones]

Thank you for your help and comments, they are much appreciated!