Bugzilla Bug 139318

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.