/usr/lib/leechcraft/plugins/libleechcraft_eiskaltdcpp.so uses internal copy of eiskaltdcpp-2.2.4/dcpp from leechcraft-0.4.90/src/plugins/eiskaltdcpp/dcpp instead of linking to /usr/lib64/libeiskaltdcpp.so.2.2
I fixed bug 386607, so there are no collisions now. QA, what we do if maintainer doesn't want to unbundle? Proxy maintainer and author at same time, in this case. 0xd34df00d, explain why you don't want to unbundle please.
Well, first I need to clarify that though I'm in touch with the upstream authors of the EiskaltDC++, I'm not the author of the plugin and I don't relate anyhow to the EiskaltDC/EiskaltDC++ project. First reason is that this plugin in LC is updated quite rarely, so I'm afraid of incompatible API breaks and such. Secondly, the porter of EiskaltDC chose to bundle the copy of the library internally, so I guess he had a reason to do so. I haven't had a chance to discuss this issue with him yet, though. Thirdly, libeiskaltdcpp is pretty non-standard library, so it's additional maintenance burden for packagers for other distros. They've asked me to bundle other libraries I use, from QXmpp to even Boost with sources, and while this reason alone isn't sufficient, but combined with others it adds a little to the final choice. To sum up, I guess we'd never throw away the library from our source base, but IMHO adding a configure switch for using already-installed version of the library would satisfy everyone. But, well, since I'm not the author, I can't decide or implement that myself, and I'd need to discuss it with the original author first.
A configure switch is quite enough indeed. I don't really care whether the sources are there as long as they are not built, so a configure option is fine for us. But it is important that the system copy is used if possible, since that means _less_ burden for us usually, and most importantly, fewer risks of security issues that need to be addressed in multiple packages.
I totally agree with you, and I also like the idea of such a switch. Nevertheless, maybe it should also be exposed as a use flag for the package — just in case the system copy changes its API too much, for example.
So, I've talked with upstream developers of EiskaltDC++ and those who ported it to LeechCraft, and, quoting them: libeiskaltdcpp uses unstable ABI and API, so using system library instead of shipped one is discouraged. Firstly, one would need to rebuild leechcraft-eiskaltdcpp after every upgrade of libeiskaltdcpp. Secondly, builds could (and would) break since the API is unstable. libeiskatldcpp exists mainly because it unifies common parts of Gtk and Qt versions of the original EiskaltDC++, and the releases of those three are tightly linked together. Unfortunately, releases of the EiskaltDC++ and leechcraft-eiskaltdcpp aren't linked that much, and that's the reason why libeiskaltdcpp is not useful for LeechCraft version of EiskaltDC++.
Package was removed from tree
