ppp bundles radiusclient in its source distribution, leading to these collisions. I'm wondering if one of you devs might be able to add radiusclient as a dependency of ppp and do some sed-fu in the ebuild to get ppp to compile against it instead of the bundled version. An additional benefit would be that it would use an up-to-date version of radiusclient (maybe even shared, unlike how it seems to be set up now?). Of course, I'm assuming the API hasn't changed, but that's for a C programmer to know. :P What do you think?
I should mention that I'm talking about the current stable ebuilds: net-dialup/ppp-2.4.2-r10 and net-dialup/radiusclient-0.4.8.
I am not ppp developer. If the upstream decides to bundle a certain version of radiusclient inside its tarball, so be it. However, you are right. ppp-2.4.2-r10 installs its own radiusclient, which should not happen since radius plugin does not depend on libradiusclient.so. I need you to make a test. Please erase /usr/lib/libradiusclient* from ppp-2.4.2-r10 installation and see if ppp's radius plugin works as expected.
RADIUS authentication continues to work correctly if /usr/lib/libradius* is removed, but fails without /etc/radiusclient.
I have second thoghts about it. We should add a "radius" flag which will add dependency on net-dialup/radiusclient...but it will be a bumpy ride. Currently, net-dialup/radiusclient has only x86 keyword; it will need same keywords as ppp. For the time being, I'll mark net-dialup/radiusclient-0.5.0 as stable, since now the configuration files are found in /etc/radiusclient-ng, which will solve collisions in /etc.
btw, can you post a patch for ppp-2.4.2-r10?
Sorry, I don't have a patch...I haven't fixed it locally. Or maybe I'm not understanding what you want. It's nearly 5am and my brain is a little soft at the moment...
I mean a patch for making ppp-2.4.2-r10 work with radiusclient-0.5.0.
That's what I thought you meant. Sorry...I have no patch to give you. I'm working production systems at the moment, and my focus is just on getting things functioning properly. I've just done without an updated radiusclient for the time being (I'm just using ppp's bundled version). Apologies...I usually like to help with a solution rather than just pointing out a problem, but in this instance I haven't had time, and don't think I will in the near future. I couldn't really do much beyond Makefile manipulation anyway, as I'm not a C Programmer.
as I stated in bug #93596, I cannot use radiusclient in net-dialup/ppp (paulus customized the radiusclient files beyond compatibility with the original version). however, this bug had a consequence. it made me realize that radiusclient-ng interface is incompatible with radiusclient interface, which means they are different libraries. I've already splitted the ebuilds into net-dialup/radiusclient and net-dialup/radiusclient-ng.
Well, at least some good came of it. Thanks for examining the issue! :)
this problem has been partially solved in ppp-2.4.2-r11. the new ebuild don't install any /usr/lib/libradiusclient* files - ppp plugins don't need them. radius plugins are statically linked with the radiusclient library compiled within.
Perhaps some seds to change its config directory to /etc/pppradiusclient or something? This would solve the rest of the collisions and allow someone to concurrently have ppp w/ radius AND radiusclient as a shared library for other purposes.
ok, I will set the default radius config dir to /etc/ppp/radius. how about that? perhaps you could post here a warning that I could use in postinst to draw user's attention on this change? although I understand English quite well, I don't master its grammar.
Why didn't I think of /etc/ppp/radius? :P How about (and only if radius is in USE): ################################################################ Warning! If you use RADIUS to authenticate PPP connections using this package, be aware that as of ppp-2.4.2-r12, the RADIUS configuration files have moved from /etc/radiusclient to /etc/ppp/radius. You will need to move those files manually! ################################################################ Note: I'm guessing about the -r12 part. :)
seems that emerge does not consider collisions in /etc. I've emerged both ppp-2.4.2-r11 and radiusclient without any error/warning, despite the fact that I have "collision-protect" in FEATURES. In this case, I would agree to move /etc/radiusclient to /etc/ppp/radius for ppp-2.4.3 (in which radiusclient is customized by ppp upstream) but not for ppp-2.4.2 (the installed files would differ only by some comments, maybe).
fixed in ppp-2.4.3-r5 because this version (2.4.3) use a customized copy of radiusclient. As I said in previous comment, there is no need for fixing it in ppp-2.4.2. This version use the original radiusclient-0.3.1, hence ppp-2.4.2 and radiusclient-0.3.2 could coexist with a shared /etc/radiusclient (which btw it isn't considered a collision by colision-protect feature of the portage).
I'm really sorry if it ends up making your life harder, but I had to report this non-detection of collisions in cfgpro dirs as bug #94116. :|
