Summary: | net-misc/neon-0.25.3 breaks subversion | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Allan Wang <allanvv> |
Component: | Current packages | Assignee: | Paul de Vrieze (RETIRED) <pauldv> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alex, betelgeuse, ceagan, dick, dragonheart, geekypenguin, ginsu.squirrel, grzegorz, gurligebis, ikelos, joe, sebastian, tetromino |
Priority: | High | ||
Version: | 2005.0 | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://subversion.tigris.org/issues/show_bug.cgi?id=2297 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Allan Wang
2005-09-10 09:22:35 UTC
ra_dav doesn't build with neon-0.25 Reproducible: Always Steps to Reproduce: 1. emerge =neon-0.25.3 2. emerge subversion 3. svn --version Output: svn, version 1.2.3 (r15833) compiled Sep 11 2005, 22:55:34 Copyright (C) 2000-2005 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme Expected output: svn, version 1.2.3 (r15833) compiled Sep 11 2005, 22:55:34 Copyright (C) 2000-2005 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). The following repository access (RA) modules are available: * ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol. - handles 'http' scheme - handles 'https' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme Yep, subversion does not like the new neon here as well. The problem is that ebuild checks ">=net-misc/neon-0.24.7", however the configure script for subversion has the version string hardcoded to "0.24.7" I suspect that the subversion configure script is probably too restrictive with the check. If the configure script can not be changed, then the ebuild will have to match the version requirement more strictly - i.e "=net-misc/neon-0.24.7" I've changed the ebuild to specifically depend on 0.24.7 *** Bug 105727 has been marked as a duplicate of this bug. *** *** Bug 105803 has been marked as a duplicate of this bug. *** (In reply to comment #4) > I've changed the ebuild to specifically depend on 0.24.7 I'm not sure if this will fix the problem. On ~ systems, neon will be updated to 0.25.3 anyway when doing emerge -uD world. Can it be package.mask'd? (In reply to comment #7) > I'm not sure if this will fix the problem. On ~ systems, neon will be updated to > 0.25.3 anyway when doing emerge -uD world. Not for me, the newer neon dependency might come from another package or you included it in /var/lib/portage/world (In reply to comment #8) > (In reply to comment #7) > > > I'm not sure if this will fix the problem. On ~ systems, neon will be updated to > > 0.25.3 anyway when doing emerge -uD world. > Not for me, the newer neon dependency might come from another package or you > included it in /var/lib/portage/world World file doesn't contain version info. Masking =net-misc/neon-0.25.3 myself causes no errors, so no other packages are depending on that version. emerge --update --deep will cause deps like neon to upgrade. (In reply to comment #9) > World file doesn't contain version info. True, but if net-misc/neon is in your world file, portage will try to update it to the latest version. Well, as long as subversion doesn't work with neon 0.25.3 , and it isn't package.mask'ed, this bug shouldn't be marked as fixed (we are getting several bug reports on this, since people have the upgrade/downgrade cycle problem). The way I see it, we have two options: 1: package.mask neon 0.25.3 2: fix subversion to work with it, or get a newer version of subversion. I personaly like option 1 best, but thats just my 0.2$ This issue is fixed in 1.3.0 RC, but mostly likely won't be backported to 1.2.x; also upstream does not seem particularly happy about shipping RC versions, so we should p.mask neon until 1.3.0 final is out. The world file may actually contain version info. But I see no reason why it should be there in the first place. I'm adding Daniel Black to the bug as I don't know why he added 0.25.3 in the first place. I don't like to break things just to help people who put neon in their world files. Isn't the real problem that portage wants to update (neon-0.25) and remove a the older version (neon-0.24.7) that is a dependency of a current package (subversion)? I'm thinking this should be blocked in the portage logic. Sure a package.mask will work in the interim but its not fixing the problem. When I added neon-0.25 I didn't anticipate this problem so my apologies to all concerned. OK, subversion-1.3.0_rc4 confirmed working with neon-0.25.3, so I guess this bug can be closed again. Just please don't mark neon stable before the new subversion. ;) Ok, I close the bug now. Please be aware though that I won't mark the rc stable at any point (it still is a rc). |