ra-dav => ra-neon and compat guarantees

I only noticed yesterday that we had renamed ra-dav to ra-neon,
and I only just now got around to looking through the list to
find the discussion. What I saw did not soothe my concerns.

We still follow these guidelines, don't we?

  http://apr.apache.org/versioning.html#binary

How have we not violated that with this rename? I understand
that--on Linux and probably other modern Unix systems--linking
-lsvn_ra-1 will not cause your binary itself to link to
libsvn_ra_dav-1, so you're OK. But, all the world is not Linux.

Furthermore, what makes us think people aren't adding
-lsvn_ra_dav-1 directly themselves? We don't even provide a
pkg-config file or anything, forcing people to handle this
themselves anyway. And, even if we did, the fact remains that we
shipped libsvn_ra_dav-1 as a public library, along with the
others. I think we need to expect applications to be dynamically
linked against libsvn_ra_dav-1 even on Linux.

Upon upgrading to 1.5, such applications will either break due to
the dav lib vanishing, or silently remain linked against a stale
lib from pre-1.5. Neither is good.

I asked on #svn-dev, and my fears were not addressed there,
either. Peter Samuelson said he originally raised this
suggestion, but noted at the time that we couldn't do it for
exactly this reason. That part seems to have been lost :-/.

The possibility of installing a symlink under the old name
pointing to the new name was raised, either handling this
ourselves in the install targets or leaving it to admins and
packagers. "Leave it to the distro" frequently amounts to "leave
it to the admin", especially when you look beyond Linux. And I'm
not confident we can determine the correct name to install the
symlink as, given that we still haven't gotten DSO working on
Darwin[1]. But, if we can make that work, I guess that's fine.
I'm not really expert here :).

Should we undo this rename?

[1] I tried to fix this once, and found two problems. The "easy"
    one to fix is hard-coded .so; Darwin needs .dylib, and, if I
    remember correctly, a slightly different filename format.
    I'm not sure how to detect this properly in configure, so I
    just made it use .dylib on Darwin and .so everywhere else.

    The second, larger problem, is that we rely on implementation
    details of Linux ld. Specifically, we just try to dlopen the
    base name of the shared object, relying on Linux ld's (IMHO
    bizarre) behavior of doing a library search in dlopen. We
    need to specify the full path. httpd prepends the ServerRoot
    to relative paths in LoadModule. I wasn't sure what we
    should do, so I shared what I learned and moved on.

-- 
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org