The new "unstable" xmlrpc-c ebuilds all forcefully disable the abyss webserver component built into xmlrpc-c. I understand that this component is old and poses a considerable security risk if not properly taken care of, but I don't think the decision whether or not to build the abyss server should be hardcoded into the ebuild. I have three reasons for this statement: firstly, by disabling it, you take all the chances of ever being maintained properly from it (bugs and security holes have to revealed before you can fix them). Secondly, a use flag could be used for those people that REALLY want the abyss server to be activated, while the default behaviour could still be set to "disabled", thus leaving a "default" system still on a reasonably high level of security. And thirdly, IMHO using something like XMLRPC or SOAP outside of a heavily secured LAN is a bad idea anyway, so I think the security considerations for the abyss webserver component are somewhat less important than they would be for a webserver software that's used in DMZ and/or WAN. I strongly suggest adding a USE flag for this one. Reproducible: Always Steps to Reproduce: 1. Add the ~amd64 keyword to dev-libs/xmlrpc-c in /etc/portage/package.keywords 2. emerge xmlrpc-c Actual Results: the xmlrpc-abyss libraries are not installed (disabled in the configure script) Expected Results: the xmlrpc-abyss libraries should be installed
Thanks for the suggestion, assigning to maintainer to consider your request.
+*xmlrpc-c-1.18.02 (27 Apr 2009) + + 27 Apr 2009; Peter Alfredsen <loki_val@gentoo.org> + +files/xmlrpc-c-1.18.02/dumpvalue.patch, +xmlrpc-c-1.18.02.ebuild: + Install tools, bug 242154. Install abyss server, bug 251718. Fix parallel + make, bug 255440. Also, bump bug 256253. +
