Subversion is well-known to be a pain in the rear to maintain as a package because each new release requires specific versions of different software. One of the conditions in the Subversion ebuild is that Apache not have a version greater than 2. I am not interested in downgrading Apache, however, it *is not required* that Apache be installed to run a subversion server. I would like to be able to somehow tell the ebuild that I do not want apache support, but USE flags don't seem to help this situation. [root@halcyon /usr/src/linux-2.4.22]$ USE="-apache2 -apache" ACCEPT_KEYWORDS="~x86" emerge -p subversion These are the packages that I would merge, in order: Calculating dependencies ...done! [blocks B ] >=net-www/apache-2* (from pkg dev-util/subversion-0.35.1) [ebuild U ] dev-lang/swig-1.3.19 [1.3.16] [ebuild N ] net-misc/neon-0.24.4 [ebuild N ] dev-util/subversion-0.35.1 Reproducible: Always Steps to Reproduce: 1. emerge subversion with apache version >2 installed 2. Try the emerge again with USE="-apache2", USE="-apache", or USE="-apache2 -apache" Actual Results: Apache is still listed as a dependency, blocking the merge. Expected Results: Apache should be removed from the dependency tree if the user sets the appropriate USE flags, because subversion also has a seperate server protocal available that is not dependant on HTTP. It is still possible to run subversion as a server without having Apache installed on your system. If Apache is not installed on your system at all, subversion will merge and not consider Apache as a dependency - I know this because I do not have Apache installed on my PC, but do on my server. I tried installing subversion on my PC to test whether or not the ebuild would force me to install Apache if I did not have it installed before submitting my bug report. This serves to further illustrate the fact that the subversion ebuilds need to pay attention to the -apache2 USE flag.
I think you want the apache2 use flag. If you have apache2 in your use flags, it depends on apache-2*. If you don't have apache2 in your use flags, then it doesn't want apache-2* installed. I think the problem lies in if you don't have the apache2 use flag, and you emerge subversion with apache-2* installed, it still links against apache-2*. I don't know if there is really a good way to handle this. Subversion is one of those packages that just sucks for a pkg mgmt system.
Brian, you're offically my hero for the evening. :) You do have a good point though. I think that for this particular program it's too hard to rely on the package manager and still have all bases cover. Here's my two cents: instead of relying on blockers, go ahead and let portage download the source. As part of the build process, execute a script before compiling the code that checks for an environment variable (AM_MASOCHIST=1). If this variable isn't present, the script spews documentation with the known quirks of this package and aborts the build. Said documentation would have a short blurb about why this package is a pain in the ass, and include a few things you need to know - like the behavior of the apache2 use flag. It would then tell the user that if they want to skip that message, merge again like so: "AM_MASOCHIST=1 emerge subversion" This would allow the package to build, and if they didn't read the warning label, oh well. While blockers and masking is generally a more elegant solution, I personally believe that this would save everyone a headache. Users would be well-informed, and the package managers would have to deal with less bug reports.
I will not have a massochist script. Basically the problem is that subversion depends on libapr and libapu. Utility libraries that come with apache-2. However the subversion tarball also contains private copies. These copies are used when the apache2 useflag is not set. Creating two copies of the apr/apu libraries is undesirable as they will create conflicts. For that reason subverion can only coexist with apache2 if the apache2 useflag is set. If you do not wish to have the server you can do that with the "-berkdb" useflag in which case the server parts will not be build. It is not possible to specify that you don't want the apache module. However this module is only a small part of the package.
Peace, peace. It was a proposed solution based on the facts on hand at the moment, and obviously such a script is unwarrented based on your explanation. The essential problem remains: the common user with apache2 already merged onto their system won't know what to do in this situation. However, my concern is placated since this bug exists to point people in the proper direction now.
So the idea is to either uninstall apache2 and then install subversion, or have them connect? Ok, this makes sense, but having apache2 whatever on you system should cause the USE=apache2 set automatically (unless disabled). The fact that you have apache2 on you system means that support for it should probably be compiled in (or am I wrong?). So let's say apache2 use flag is not set but apache2 is still installed (as it seems most systems won't have it set), isn't there a way to say we won't compile support for it but we still want to use those two scripts from it? In the case where apache2 use flag is set it is simple, ensure apache2 is installed and continue. Also the case where apache2 is not installed and the use flag is not set is simple.
Basically yes. There is currently no way to have apache2 installed and to build the subversion server part (berkdb flag) but not to have the apache2 module. This module is only small so I don't think it is a problem. This module will not be automatically enabled at all. Basically in case apache2 is available, but apache2 is not in the use flags we will get a plain old file conflict. Both provide the apr/apu libraries. It are not mere scripts, so the only other solution would be either to require apache2 in all cases, or if apache.org would finally make a standalone release of apr.
The last problem I experience with this ebuild is that if apache is already installed but the apache2 use flag is not set it chockes. Is there no way in which we can print out a nice bit of information as to why - this took me a quite a while and a lot of reading to figure out, and that just to try subversion out before I switch all my projects to it! Seems to be getting going now. This being the last little issue (having to execute 'USE="apache2" emerge subversion'). This is probably an apache2 issue though, my understanding is that as soon as a package such as apache gets emerged the apache2 use flag should be set by default, unless disabled in /etc/make.conf - or am I wrong in this?
When last has anyone done an "emerge -s ^apr$"? Well, I just found this: * dev-libs/apr Latest version available: 0.9.2 Latest version installed: [ Not Installed ] Size of downloaded files: 1,465 kB Homepage: http://apr.apache.org/ Description: Apache's Portable Runtime Library. License: Apache-1.1 I don't think it's that usefull, and instead have chosen to go another route. I have also done: # find / -name "apr" 2>/dev/null /usr/portage/dev-libs/apr /home/jaco/src/subversion-0.37.0/apr In order to try and use the --with-apr=??? configure option in an attempt to compile without apache2 support, but use apache2's apr utility (there is however an apr-config program). Any ideas? I have apache-2.0.48 on my system, but not the above mentioned apr ebuild. Can anybody else confirm this? The same goes for apu (apu-config, but no apu). Both the -config progs are part of apache. Ok, just noticed this from "./configure --help" --with-apr=DIR|FILE prefix for installed APR, path to APR build tree, or the full path to apr-config The important part being apr-config. I'm going to modify the ebuild to make use of this *if, and only if* apache2 is installed. The same goes for the apu-config. This has the disadvantage that should apache then be unmerged, then subversion will most likely break (anybody willing to test that?). revdep-rebuild should pick that up though. Another issue (if the previous is an issue) is that binary builds might break if apache2 is installed on the building system, but not on the target system.
Created attachment 25295 [details, diff] subversion-0.37.ebuild.patch (attempt at "fixing" apache issues) Just a patch on subversion-0.37.ebuild, my attempt at sorting out these issues with apache. Would be appreciated if somebody else can take a look.
The patch is broken. The dependency change would disallow apache 1 to be installed. Quite certainly not a good idea. Further using has-version to dynamically link with apache2 will break binary packages by basically ignoring the concept of specifying dependencies. Further it is not true that one can use an apache smaller than 2.0.48 concurrently with subversion in any case. It will cause overwritten files, not a good idea.
Actually revdep rebuild will not catch the apache 2 removed issue as you sidetrack the dependency tracking. Revdep-rebuild will believe that subversion never depended on apache2 at all. (Apache2 will even be cleaned by emerge depclean if it is not depended on by other packages)
