dev-util/subversion-0.32.1 is in portage, in meantime that was two releases. for now subversion-0.34.0 is actual. that not a major upgrade so probably only coping an ebuild is needed Reproducible: Always Steps to Reproduce:
Actually, the subversion virtual filesystem schema was changed in this release, so a dump/load is needed when upgrading to 0.34.0. This happened also with 0.28 release. The ebuild seems to download a statically linked svnadmin-0.27 and just unpack it to /usr/lib/subversion/bin/svnadmin-0.27 (without execute permissions!). This approach is just _wrong_. Maybe ebuild for 0.34.0 should automatically dump the repository in pkg_setup and restore it in pkg_postinst. This way there wouldn't be a need for bunch of old statically linked binaries. See the CHANGES file http://svn.collab.net/repos/svn/tags/0.34.0/CHANGES and http://svn.collab.net/repos/svn/tags/0.34.0/notes/repos_upgrade_HOWTO repos_upgrade_HOWTO has some old version numbers in it (0.28) but the dump/load procedure is the same. I might have time to upgrade the ebuild at the end of the week.
Automatic dump/load is a bad idea. I have many repositories in non-standard places and configurations and I fear what would such automatics do with them. Leaving just a message how to dump/load will be fine IMHO... Thanks... Radek
Created attachment 21931 [details] working ebuild (from subversion-0.32.1.ebuild) I commented out db patch, cause even with 0.32.1 it makes troubles. Need to be revised by some who knows ebuild better that me.
*** Bug 35541 has been marked as a duplicate of this bug. ***
*** Bug 33541 has been marked as a duplicate of this bug. ***
Yes, I now agree that automatic dump/load is very, very bad. But so is the precompiled static binary. So the warning message is enough. I found a load of bugs while going through the old ebuild, like testing "if [ -f foo ]" on _directory_, unneeded use of ${PN}-${PV} etc. And the ssl USE-flag affects only while using the internal version of neon. All in all, the 0.32.1 ebuild is a real mess. Oh.. one more thing.. the default SVN_REPOS_LOC is /home/svn, and installing stuff like this under /home is yet another wrong way to do things. Maybe /var/lib/svn would be a better alternative. I'll post a somewhat fixed ebuild soon, but I'm not willing to dive in to that src_compile() mess.
I agree default location should be changed to /var/svn (to match /var/www) instead of /home/svn.
Created attachment 22088 [details] subversion-0.34.0.ebuild with some fixes - changed the default repository location to /var/lib/subversion - fixed "if [ -f ..." to "if [ -d ..." in pkg_config() - changed the warning message a bit and added a simple countdown - commented out WANT_AUTOCONF setting (it _seems_ to work, needs testing) - removed db4 patch - some ${PN}-${PV} -> ${P} and ${A} changes - removed the static svnadmin-0.27 binary (0.34.0 changed the schema again), and I guess nobody ever used that (it was chmod 644 btw ;)
So what else is needed before this is added to the portage tree?
The attached ebuild appears to work fine when the apache2 use variable has been set, but when this variable hasn't been set I get the following error: configure: error: can only configure for one host and one target at a time configure failed for apr !!! ERROR: dev-util/subversion-0.34.0 failed. !!! Function econf, Line 338, Exitcode 1 !!! econf failed
The announcement e-mail for 0.34.0 recommends Berkeley DB 4.2.50. 4.1.25 is still marked unstable and there is no ebuild yet for 4.2.x. Does it work OK with the latest stable version of BDB (4.0.14-r2)?
Am I missing something? Subversion is now on 1.0.1, I think this should be closed... Radek
1.0.1 is out and in the tree so this can be closed
