On 8/2/07, Eric Gillespie <email@example.com> 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?
> 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. 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?
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Aug 3 00:11:53 2007