Davix bundles an old version of libneon

[amadio]

Could Davix please offer the possibility to build against an external libneon package? I intend to package Davix in Gentoo Linux for use as a dependency by ROOT, but in Gentoo packages must not bundle any dependencies. When trying to use an external libneon, I noticed that neon-0.30 (available in Gentoo) is incompatible with neon-0.29 bundled in Davix.

[gbitzes]

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)

[amadio]

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?

[gbitzes]

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.

[amadio]

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.

[gbitzes]

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.

[gbitzes]

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.

[amadio]

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.

[gbitzes]

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.

[amadio]

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.

[adevress]

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.