Bug 995688 - Remove bundled libraries from davix
Remove bundled libraries from davix
Product: Fedora
Classification: Fedora
Component: davix (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Adrien Devresse
Fedora Extras Quality Assurance
Depends On:
Blocks: DuplicSysLibsTracker
  Show dependency treegraph
Reported: 2013-08-10 01:59 EDT by Mattias Ellert
Modified: 2013-11-06 08:46 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-11-06 08:46:51 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mattias Ellert 2013-08-10 01:59:36 EDT
Description of problem:

The davix source tree contains many libraries that should be unbundled according to the guidelines.



 → Use BuildRequires: neon-devel instead


 → Use BuildRequires: libbsd-devel instead
   #include <bsd/string.h>


 → Use BuildRequires: gtest-devel instead


 → Use BuildRequires; pywebdav instead

Other code in the deps/* directories should be investigated to assess whether they are bundled or not.

Unused bundled code should be deleted in %prep so that it is no accidentally used during the build.

Version-Release number of selected component (if applicable):


Additional info:

There are some other minor packaging issues in the spec as well:

The main davix package depends on the davix-libs package and these are build from the same srpm → the davix package should have a fully versioned dependency on davix-libs:

Requires: %{name}-libs%{?_isa} = %{version}-%{release}

The doc subpackage should be noarch where supported, i.e. except on EPEL 5:

%if %{?fedora}%{!?fedora:0} >= 10 || %{?rhel}%{!?rhel:0} >= 6
BuildArch:	noarch

The doc package depends on the main package, but contains documentation about the api of the library, so this dependency does not make sense. It could depend on the library package instead, or have no dependency at all. (If the dependency is removed the LICENSE file should be added to the doc package.)
Comment 1 Adrien Devresse 2013-08-12 10:30:53 EDT
Hi Matthias,

Thank you for your bug report and your remarks.

But please keep in mind that davix has been packaged in a preview and beta stage for user feedback purpose ( version < 1 for now ) and most of the problems you are refering too are under corrections or already corrected upstream.

However concerning libneon, even if the name leads to confusion, this is not a bundle library : davix can't compile with a standard libneon dependency. 

The src code inside deps/libneon has been heavily modified for VOMS, grid specific authentication support ( PEM, chains, etc.. ), grid extensions supports, S3 etc ... and can't be considered as "neon" anymore and will even more derivate from neon in future.

These modifications can not be integrated upstreams too, they derivate completely from the original libneon aim and are grid specific.

However and if needed because of any name conflict, we can proceed to the renaming of the source code of this component.

Comment 2 Adrien Devresse 2013-09-17 04:14:27 EDT
The changes for this problems have been applied and are now deployed under EPEL testing with the 0.2.4 version.

Note You need to log in before you can comment on or make changes to this bug.