I have the ssl USE flag enabled, but I don't have either of the openssl or the gnutls USE flags set. When I emerge lynx, it's built without SSL support, which seems counterintuitive. Rather than being ignored completely, I would expect the ssl USE flag to trigger a dependency on (openssl || gnutls), with those USE flags selecting which implementation to use if one is enabled. Reproducible: Always
I'm not convinced that having all three USE flags of ssl, openssl, and gnutls would be less confusing than the current combination of just openssl and gnutls. There is no precedent of current ebuilds using all three flags; in fact, there are none that have both openssl and ssl. * What would it mean to have setting: -ssl +openssl +gnutls * How about: +ssl -openssl -gnutls Of course you could pick some precedence among the flags, but the meaning would not be at all obvious. I think the current combination of openssl and gnutls use flags is the most unambiguous, with the only question being what happens when both are enabled. Usually openssl seems to be the default SSL implementation, and in this case it is further clarified by an info message in pkg_setup: "Both openssl and gnutls use-flags specified. Openssl will be used." I can see how someone might overlook the change in lynx flags from ssl to openssl and gnutls, but at least there is an info message in pkg_setup pointing out SSL is disabled if both openssl and gnutls are disabled.
BTW there is another option of switching openssl flag back to ssl, and thus the combination of ssl and gnutls flags. * What would this mean: +ssl +gnutls This normally means gnutls is chosen as SSL implementation, overriding the default of openssl. I think this behavior is pretty consistent across ebuilds. * What would this mean: -ssl +gnutls This is where the ambiguity comes in. Some ebuilds take this to mean gnutls is enabled (same as "+ssl +gnutls"), and some interpret it as ssl completely disabled (same as "-ssl -gnutls").
By the way, sorry it took a month to respond to your bug; you happened to hit a transition time between lynx maintainers. Also, I am interested in suggestions on making the USE flags more intuitive, and would be happy to hear your ideas on the usability issues I raised. I didn't mean to blow off your suggestion, just haven't yet thought of a way to implement it without adding confusion in other situations. So, if you don't have anything else to add to this discussion, I'll probably close this bug as "LATER", hoping to come up with a better alternative.
I suppose the problem is that the ebuild has to select one of three options (no ssl, openssl, or gnutls) with booleans, so there's always going to be one extra combination of use flags. XD From a user perspective, it's much more common to want SSL enabled than to specifically want openssl or gnutls disabled, I think. I think you're right that having three use flags for this raises too many ambiguous cases, so IMO having ssl mean openssl would be better. With the "-ssl +gnutls" case, I notice that ssl is enabled by default in my profile (dunno about others?), so for that to come up a user would have to explicitly disable ssl and then explicitly enable gnutls in their use flags! I'd say in that case that gnutls should be used, but I don't think that case really matters so much.
You make a good point about ssl flag but not openssl flag being enabled by default in popular profiles. I'll go ahead and make the switch after tracking down the compile breakage problem for openssl with USE=kerberos; hopefully sometime this weekend. Thanks for your feedback :)
I don't know if this will help you or simply confuse the issue. lynx-2.8.7_rc6 fails for me with the following: W/Library/Implementation/ -DACCESS_AUTH -c ../../../WWW/Library/Implementation/HTBTree.c x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I../../.. -I../../../src -I../../.. -I../../../src -I../../../WWW/Library/Implementation -D_GNU_SOURCE -DLINUX -I/usr/kerberos/include -I/usr/include/ncursesw -march=opteron -O2 -pipe -I../../../WWW/Library/Implementation/ -DACCESS_AUTH -c ../../../WWW/Library/Implementation/HTFTP.c In file included from ../../../WWW/Library/Implementation/HTParse.c:8: ../../../WWW/Library/Implementation/HTUtils.h:710:17: error: ssl.h: No such file or directory ../../../WWW/Library/Implementation/HTUtils.h:711:20: error: crypto.h: No such file or directory ../../../WWW/Library/Implementation/HTUtils.h:712:18: error: rand.h: No such file or directory In file included from ../../../WWW/Library/Implementation/HTParse.c:8: ../../../WWW/Library/Implementation/HTUtils.h:751: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token In file included from ../../../WWW/Library/Implementation/HTFTP.c:63: ../../../WWW/Library/Implementation/HTUtils.h:710:17: error: ssl.h: No such file or directory ../../../WWW/Library/Implementation/HTUtils.h:711:20: error: crypto.h: No such file or directory ../../../WWW/Library/Implementation/HTUtils.h:712:18: error: rand.h: No such file or directory In file included from ../../../WWW/Library/Implementation/HTFTP.c:63: ../../../WWW/Library/Implementation/HTUtils.h:751: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token In file included from ../../../WWW/Library/Implementation/HTTP.c:12: ../../../WWW/Library/Implementation/HTUtils.h:710:17: error: ssl.h: No such file or directory ../../../WWW/Library/Implementation/HTUtils.h:711:20: error: crypto.h: No such file or directory ../../../WWW/Library/Implementation/HTUtils.h:712:18: error: rand.h: No such file or directory In file included from ../../../WWW/Library/Implementation/HTFTP.c:69: ../../../WWW/Library/Implementation/HTTP.h:35: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token In file included from ../../../WWW/Library/Implementation/HTTP.c:12: ../../../WWW/Library/Implementation/HTUtils.h:751: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token In file included from ../../../WWW/Library/Implementation/HTTP.c:13: ../../../WWW/Library/Implementation/HTTP.h:35: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token In file included from ../../../WWW/Library/Implementation/HTTP.c:17: ../../../WWW/Library/Implementation/HTNews.h:48: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token make[1]: *** [HTParse.o] Error 1 make[1]: *** Waiting for unfinished jobs.... In cases similar to these where there is a complaint that a file is missing, I normally re-emerge the owning package. In this case: libwww. In this case, that didn't help. lynx-2.8.6-r4 compiles without any complaints on my system. These are the 2.8.7-rc6 USE options: [ebuild U ] www-client/lynx-2.8.7_rc6 [2.8.6-r4] USE="bzip2 gnutls%* ipv6 nls openssl%* unicode -cjk (-ssl%*)" LINGUAS="(-ca%) (-cs%) (-da%) (-de%) (-et%) (-fr%) (-hu%) (-it%) (-ja%) (-nl%) (-pt_BR%) (-ru%) (-rw%) (-sl%) (-sv%) (-tr%) (-uk%) (-vi%) (-zh_CN%) (-zh_TW%)" 0 kB These are the 2.8.6-r4 USE options: [ebuild R ] www-client/lynx-2.8.6-r4 USE="bzip2 ipv6 nls ssl unicode -cjk" LINGUAS="-ca -cs -da -de -et -fr -hu -it -ja -nl -pt_BR -ru -rw -sl -sv -tr -uk -vi -zh_CN -zh_TW" 0 kB I hope this helps. If not - please ignore it. And thank you for your time and effort. It is sincerely appreciated.
Guy, would you be willing to put lynx-2.8.7_p1 into a local overlay and apply the ebuild patch I attached to bug 267749? If so, please report your build results under bug 267749 (which is on the topic of compile issues caused by openssl compiled with kerberos -- the failures look identical to yours, so I'm guessing you have kerberos useflag).
Wormo, I do indeed have "kerberos" set. I really, really do hate to admit this, but I no longer understand how to set up overlays anymore. I've tried to understand the "layman" package but have not managed to successfully install it. There is some concept I'm missing and I can't seem to get past that gap. I used to occasionally create manual overlays before the existence of "layman" back in the early days of "freenx" (with explicit step by step instructions). I understand the underlying concept of overlays but I've removed all of the overlay directories I used to have after emerge started to complain about 'repoman' and stuff like that. If you would like me to test this, I'd be most willing but doing so will mean explicit set up instructions. You can discuss this further or send me instructions to my gmail account. I'd even be willing to provide you a phone number where you can talk me through doing this. {ulterior motive - I'd like to understand what I'm missing regarding "layman} I've read through bug# 267749 and your supposition that these are the same issue seems very reasonable. Of course, I'm not a programmer ... :) Take care, Guy
useflag change committed to cvs
