Bug 418331 - Make kdsoap an optional dependency
Summary: Make kdsoap an optional dependency
Status: RESOLVED NOT A BUG
Alias: None
Product: kio-extras
Classification: Frameworks and Libraries
Component: default (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-02-29 17:31 UTC by Nate Graham
Modified: 2020-03-23 16:28 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nate Graham 2020-02-29 17:31:24 UTC
Could not find a package configuration file provided by "KDSoap" (requested
  version 1.8.50) with any of the following names:

    KDSoapConfig.cmake
    kdsoap-config.cmake

  Add the installation prefix of "KDSoap" to CMAKE_PREFIX_PATH or set
  "KDSoap_DIR" to a directory containing one of the above files.  If "KDSoap"
  provides a separate development package or SDK, be sure it has been
  installed.



Right now it's a mandatory dependency, but many/most distros (including Neon) haven't even packaged it yet. Consider making it an optional dependency.
Comment 1 Harald Sitter 2020-03-04 16:53:48 UTC
We've talked about it elsewhere and since we want distros to get kdsoap packaged sooner rather than later it's better if it is not optional. It sucks that this makes building master a lot less accessible for now, but in the end the only supported line-up for master moving forward is having smb with kdnssd and wsdiscovery support. So, the required-dependency does accurately represent the feature expectations here and the code is written that way also (i.e. making kdsoap optional would also require some ifdeffing on the code side).

As a stop gap measure I'd suggest building without smb -DCMAKE_DISABLE_FIND_PACKAGE_Samba=ON if building kdsoap is not an option. Kdsoap only depends on Qt and has a cmake build system, it really isn't that hard to build if need be though.
Comment 2 Luca Beltrame 2020-03-23 15:16:13 UTC
Currently there are licensing issues in kdsoap (EULA shipped in the source package which is incompatible with the other licenses there). Unless these are fixed, packaging kdsoap properly is a non-starter.
Comment 3 Harald Sitter 2020-03-23 16:17:03 UTC
The readme does say the eula only applies to commercial licensing.
Comment 4 Luca Beltrame 2020-03-23 16:22:27 UTC
It's still included in the distributed tarball, which shouldn't happen. I have filed an issue upstream already.
Comment 5 Harald Sitter 2020-03-23 16:28:28 UTC
Well, let's get it changed in kdsoap then :)

In the debian world when there is stuff that the policy has objections to the tarball is usually repacked without the objectionable content, effectively reducing the code to the DFSG-compliant, free license, bits. Perhaps something similar could be done as a stop-gap here. As I say, the readme makes it very clear what the terms of licensing are.