Subversion ebuilds need to be updated to dep on APR 0.9.x or basically APR slot 0. APR 1.x might be unmasked soon and could cause breakage with the current >= deps of APR. Would have done it myself, but not my package. If you would like me to address just say so. Otherwise please address when you have time, no rush. Thanks.
Actually subversion should work correctly with 1.0 apr's too. I'll test it though.
That's fine, it's just any reference to like apr-config would need to be changed to apr-1-config, or the base dir of /usr/share/apr-0 would change to /usr/share/apr-1. Which is most of the reason to make sure the dep brings in a specific slot. Or the rest of the use of the apr stuff in the ebuild, would likely fail or etc. Unless someone has both present :)
Subversions deps were changed to pull in =apr-0*, which will surely work and coincides with slot 0 (slot deps are not yet ready, we'll use those once they are). When you've tested Subversion with apr-1* just update the ebuilds and change the deps... Best regards, CHTEKK.
*** Bug 167522 has been marked as a duplicate of this bug. ***
apache-2.2.4 requires slot 1, and subversion's mod_dav_svn *must* be built with the same apr slot as apache, or bad things will happen. OTOH, as commented in the bug marked as duplicate, most modern subversions (of course 1.3* and 1.4* **require** >apr-util-0.9.7 (google for it), and all run with apr-util-1* So, the changes was negative for people running experimental apache, and could regress some bugs due to subversion-1.3* requiring apr-util > 0.9.7 The bug is not fixed (it is not really a gub, but a command, and a wrong one), and it is introducing a new one for people using apache-2.2, and potential regressions for people using subversion-1.3 wit old apr-0. I checked with ASF/Subversion developers before commenting here, and they agreed with my position.
I have changed the dep on the latest subversion (1.4.3) to allow both, and not depend on apr at all when it depends on apache (as apache already pulls in apr), and we need the one used by apache.
Cool, looks like a cleaner solution, as typically apache "stress" apr more (it is developed primarily for the httpd server), and the requirement to have at least the same slot in httpd and mod_dav_svn.so was hard (IIRC), as both end up linked together in the apache process
