Davix bundles an old version of libneon about davix HOT 10 OPEN

Hi, this is not possible right now, as the bundled version of libneon currently contains many modifications. Most of them were made by previous developers, I'm not quite sure at this point what is vanilla libneon, and what was modified by us.

Is there a reason not to use the bundled version? From looking at the libneon website, development of the library has mostly stopped, and the last few versions only contained minor modifications (compatibility with newer openssl for example, which we also have)

from davix.

Yes, the reason is that Gentoo Linux's policies are against bundling of dependencies if they are already packaged in Gentoo.

I talked to @Axel-Naumann about future plans for ROOT regarding Davix, and libcurl came up. Do you think that Davix could move to using libcurl instead of neon in the future?

from davix.

I've actually been planning to do this, dropping libneon in favour of libcurl - this will also give us asynchronous IO and pipelining. It's also (much) better supported than libneon.

I can't give an estimate for when, though - my time is currently spread very thin. Once I'm mostly done with some very high priority projects, I'll have more time to dedicate to davix, and start the transition to libcurl.

from davix.

That's very useful to know. Thank you! Do you remember what changes were made to libneon, more or less? I tried to port to neon-0.30, and I don't think too many changes are necessary, actually. But I don't know how much you rely on changes in neon. I can create a PR with the changes I've made if you'd like.

from davix.

I inherited davix after most of the changes to libneon had already been made. I think, the most important ones are related to timeouts. There's also an important bugfix related to some OpenSSL refcounts, which were being incremented / decremented in a non-atomic way, leading to intermittent crashes.

PR's are welcome, of course.

Maybe a diff between the bundled version and the newest one could come in handy, but I'm not sure where to find the latest libneon, the website seems down.

In any case, we would probably not want to link dynamically with libneon, so it would stay "bundled", I'm not sure if that's OK by Gentoo.

from davix.

Since most recent libneon changes were small, this might be the easiest option: Diff between vanilla 0.29 and 0.30 libneon, and then try to backport the updates into the bundled, davix libneon.

from davix.

In any case, we would probably not want to link dynamically with libneon, so it would stay "bundled", I'm not sure if that's OK by Gentoo.

The problem I see is that there may be symbol clashes when linking against Davix and libneon, but it's a minor issue. When Davix is built with the option to build static libraries, libneon.a should not be installed, or Davix and libneon from Gentoo would create file collisions in the filesystem, preventing neon to be installed on the same system.

from davix.

I noticed this problem many months ago, thinking that libneon.a should not be installed, since it's our heavily modified version, and could clash with the system library.

Should be easy to do, but after a day of wrestling with cmake on SLC5, I admitted defeat and postponed it indefinitely.

If libneon.a is not installed with "make install", will this fix your Gentoo issue? I can try again, this looks much easier to do than backporting libneon.

Here's the ticket from 2016 😛
https://its.cern.ch/jira/browse/DMC-834

Since we don't have to support SL5 anymore, I can simply switch to cmake3, and get this fixed in a clean way.

from davix.

Let me see what I can get done this weekend on this and we can take it from there. If I can't find a way to build against neon-0.30, I will add it as is now and wait for an update with libcurl.

from davix.

Plop, I'm the one that bundled libneon in davix in the first place. At this time, libneon was the 'best' available librarie in C supporting low level WebDav operations properly.

Since, libneon inside Davix has been patched several time for specific things like "thread safety or auto retry on timeout".

The problem I see is that there may be symbol clashes when linking against Davix and libneon, but it's a minor issue

It's even a non existing issue if symbols are flags properly and not exposed.

When Davix is built with the option to build static libraries, libneon.a should not be installed, or Davix and libneon from Gentoo would create file collisions in the filesystem, preventing neon to be installed on the same system.

For this one, renaming libneon from davix as libneon_davix would fix your issue. It's bundle anyway and patch, it should not be used a a libneon.

from davix.