ra-dav => ra-neon and compat guarantees

[Eric Gillespie <ep...@pretzelnet.org>]

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

Re: ra-dav => ra-neon and compat guarantees

[David Glasser <gl...@davidglasser.net>]

On 8/3/07, David Glasser <gl...@davidglasser.net> wrote:
> On 8/2/07, Eric Gillespie <ep...@pretzelnet.org> wrote:
> > 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.
>
> Just for the record, this is issue 2800.
>
> I physically did the rename, but will happily admit that I am not an
> expert on linking, and am certainly concerned that we need to make
> sure this is compatible or revert it.

We could also consider a compromise solution:

* Build the library in a file called libsvn_ra_dav
* Refer to the library as "neon" in "svn --version" and the
http-library configuration setting
* Use the svn_ra_neon__* namespace for symbols (though this could go
either way).

I guess it's a usability question: is it more important for the
library filename to match what it's referred to as in the application,
or for the choice the user makes in the application to use the more
relevant names?

--dave

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ra-dav => ra-neon and compat guarantees

[David Glasser <gl...@davidglasser.net>]

On 8/2/07, Eric Gillespie <ep...@pretzelnet.org> wrote:
> 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.

Just for the record, this is issue 2800.

I physically did the rename, but will happily admit that I am not an
expert on linking, and am certainly concerned that we need to make
sure this is compatible or revert it.

--dave

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ra-dav => ra-neon and compat guarantees

[Malcolm Rowe <ma...@farside.org.uk>]

On Thu, Aug 02, 2007 at 03:23:14PM -0700, Eric Gillespie wrote:
> actually accomplish anything, but it is feasible.  I can even see
> a semi-legitimate reason: reusing the ra_svn marshaling functions
> (semi in that I expect we discourage that and do not support it,
> but at least I can imagine why someone would try anyway, whereas
> I don't see that with ra-dav).
> 

Note that (some of) the ra_svn functions are actually real public
symbols - see include/svn_ra_svn.h.  I believe this is for historical
reasons only, as the other RA/FS exports are all private (e.g.
svn_ra_serf__foo), with the exception of e.g. svn_ra_serf_init().

Regards,
Malcolm

Re: ra-dav => ra-neon and compat guarantees

[Eric Gillespie <ep...@pretzelnet.org>]

"Mark Phippard" <ma...@gmail.com> writes:

> Could we go back to libsvn_ra_dav-1.so and have it contain Neon and Serf?

I like this.  Since we can link both into the same process today,
they obviously don't export the same symbols, so it should work.

> Given that the library did not contain public symbols could we just
> create a dummy library for compatibility?

We may advise people not to use them, but they are certainly
public symbols.  I can build an application and reference them
directly.  I probably can't write a small example that would
actually accomplish anything, but it is feasible.  I can even see
a semi-legitimate reason: reusing the ra_svn marshaling functions
(semi in that I expect we discourage that and do not support it,
but at least I can imagine why someone would try anyway, whereas
I don't see that with ra-dav).

-- 
Eric Gillespie <*> epg@pretzelnet.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ra-dav => ra-neon and compat guarantees

[Mark Phippard <ma...@gmail.com>]

On 8/2/07, Eric Gillespie <ep...@pretzelnet.org> wrote:
> 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?

On Windows we are just adding DLL's with 1.5.  I noticed we get a
single libsvn_ra-1.dll and it contains the Neon and Serf
implementation.  Given that libsvn_ra is where the public interface
lives, this seems like how it should have always been done on other
platforms too.  I assume it is too late for that?

Could we go back to libsvn_ra_dav-1.so and have it contain Neon and Serf?

I do not know how long we should wait for someone to propose an
alternate solution, but if the current trunk breaks the compatibility
than maybe we should just undo the rename.  If we want the library
renamed for aesthetics then the compatibility issues ought to be
resolved at the same time or we ought to not do it in the first place.

Given that the library did not contain public symbols could we just
create a dummy library for compatibility?

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org