net-misc/neon-0.26.1 broke my subversion install, which was first linked against libneon.so.25. The neon ebuild should do something like the following: ewarn "Please run 'revdep-rebuild --library=libneon.so.25' to fix breakage." (looks like davfs2 was also broken, after running the above)
So, net-misc/neon-0.26.1 should be a blocker for <subversion-1.3.2-r1, as subversion-1.3.1 dies explicitly complaining about neon > 0.25. *sigh* this is what I get for reporting before the build completed ;-)
Well, honestly that's what you get for mixing stable and ~arch ebuilds... ;)
indeed -- but three things: - bugs reports are how I take part in gentoo - I try to use ebuilds for devlopment libraries I use day-to-day, rather than compiling from scratch myself and just using that to help test ebuilds as much as possible - there's no reason subversion or neon can't have explicit information for dependencies added rather than non-specific (>=net-misc/neon-0.26.1 versus net-misc/neon) ... but again, I completely understand your perspective. :-)
Since neon seems to have a tendency to break API on new versions (bmpx hit this as well, see bug #139488). Maybe it would be a good idea to SLOT it. I can do the work to make it SLOT'ed as long as I get an ok from the maintainer (pauldv).
(In reply to comment #4) > Since neon seems to have a tendency to break API on new versions (bmpx hit this > as well, see bug #139488). Maybe it would be a good idea to SLOT it. > > I can do the work to make it SLOT'ed as long as I get an ok from the maintainer > (pauldv). > I agree. I'm running a supposedly 'stable' x86 system. However, I now have a portage emerge loop after the last sync. The current stable version of dev-util/rapidsvn requires "DEPEND="~net-misc/neon-0.24.7". However, the current stable version of gnome-base/gnome-vfs requires the newer neon version ie "Depend >= net-misc/neon-0.25.3". No matter which one I pick, one app or the other won't build. The neon API changes far more often than is sane for a library, however, glancing over the neon website it appears the main intent of the developers is that the neon source should be 'embedded' within the actual apps, not linked as a library. Given this philosophy, it seems to me that the best long-term solution for the neon 'library' is to slot it.
After taking a closer look at neon, it isn't a SLOT-able package, the headers are always installed at /usr/lib/neon, and there is no versioning on them. The man pages are also not versioned, not to mention that it installs libneon.so, which again is unversioned.
I'm running stable and ran into a similar problem as the poster in comment #5. gnome-base/gnome-vfs-2.14.2 pulled in net-misc/neon-0.25.3 which then broke dev-util/subversion-1.3.2-r1. At minimum, I think an ewarn message is required.
conflict between stable packages: net-fs/davfs2/davfs2-0.2.8.ebuild: <net-misc/neon-0.26 dev-util/subversion/subversion-1.3.2-r1.ebuild: >=net-misc/neon-0.26 (I just added >=net-misc/neon-0.26 >=dev-util/subversion-1.3.2 to package.mask as a workaround.)
But.. subversion 1.3.2-r1 works with neon-0.25.3! I installed davfs2, which downgraded neon to 0.25.3. Then subversion didn't work anymore, because it was linked neon-0.26. Then I did 'emerge -O subversion' and subversion 1.3.2-r1 compiles and links cleanly against neon-0.25.3. For me, svn works perfectly again. I verified libneon is actually used by compiling svn without the 'nowebdav' USE flag. Then it didn't recognise the https:// scheme anymore. So you might want to modify the >=neon-0.26 requirement for subversion-1.3.2-r1. All this was verified both on x86 and amd64 installations.
This combination works here: [I] net-fs/davfs2 (1.1.1) [I] dev-util/subversion (1.4.0) [I] net-misc/neon (0.26.1-r1)
<i>"...glancing over the neon website it appears the main intent of the developers is that the neon source should be 'embedded' within the actual apps, not linked as a library."</i> If this is so (should be confirmed) then this bug really is a subversion bug, isn't it?
To confirm the quoted text, here a quote from the neon documentation: file:///usr/share/doc/neon-0.26.1/html/using.html How to use neon from your application ... The neon source code is designed to be easily embedded into an application source tree. ... This means the bundled neon source directory (called 'libneon') is used if no neon is found on the system, and the standard XML parser search is used. This means, effectively, that apps should not rely on (the right version of) neon being present on the system but use their embedded version of neon in case. And in fact, the subversion source contains an embedded version of neon. SOLUTION: Define the nowebdav use flag if you have problems with neon dependencies, as then subversion will compile its own neon version! REDCOMMENDATION: Rename nowebdav to something fitting like shared_neon and make !shared_neon the default.
(In reply to comment #12) > To confirm the quoted text, here a quote from the neon documentation: > file:///usr/share/doc/neon-0.26.1/html/using.html > > How to use neon from your application > ... > The neon source code is designed to be easily embedded into an application > source tree. > ... > This means the bundled neon source directory (called 'libneon') is used if no > neon is found on the system, and the standard XML parser search is used. > > This means, effectively, that apps should not rely on (the right version of) > neon being present on the system but use their embedded version of neon in > case. And in fact, the subversion source contains an embedded version of neon. > > SOLUTION: Define the nowebdav use flag if you have problems with neon > dependencies, as then subversion will compile its own neon version! > > REDCOMMENDATION: Rename nowebdav to something fitting like shared_neon and make > !shared_neon the default. > I am afraid, I don't understand you. Is your solution for the end user or for the ebuild developer? Because the current ebuild doesn't work this way. If I use "nowebdav" with the current ebuild (1.4.2) it does what it says: no webdav support is compiled at all. Such a subversion is useless for me, because I need https and http url scheme support with subversion. I also can't find any embedded neon sources in the source tree after doing "ebuild subversion-1.4.2.ebuild unpack".
because neon is no longer included with svn (it was in the stable 1.3.2), solution is no longer possible. But then, as stated, this becomes an upstream problem since neon is no longer used by the app as intended.
This bug indeed is messy. I'll think about what we can do. I'll probably have to fix neon to do the right thing. Something I'm not exactly looking forward to ;-/
>=subversion-1.3.2-r3 is stable everywhere now -> issue FIXED.
