Am 06.11.2015 um 13:24 schrieb Gianfranco Costamagna: Hi, > yes, but let assume one of the libraries above have a security bug. > you will need to do a source only upload, instead of just fixing the > library and rebuild the affected packages (assuming there will be one > day more packages using the above libraries you can always ship them > as source only libraries, e.g. > https://packages.qa.debian.org/w/websocketpp.html (unless the > libraries are strictly internal and makes no sense outside this > particular project) I understand the problem. I've taken a look into the cmake file and I found out that libjreen does not use "icesupport" automatically.
→ option(JREEN_USE_IRISICE "Use ICE from IRIS" OFF) On the other side libjreen is looking for a external JDNS. And so it would be really better to create a libjdns package for debian, or? > I know, but you are Debian-patching an upstream issue. you are > workarounding it, not fixing (even if it works). I would appreciate a > proper fix and a patch sent upstream (in the meanwhile you can of > course use this solution, It came in my mind, but I didn't suggest it > because I don't think it is the best way) Please correct me if I'm wrong, but I do not agree in your opinion because other distributions uses another way of multiarch support. For example openSUSE, they uses the path "/usr/lib64/libjreen.so.1". And so I think it is impossible to upstream a patch, which changes "DESTINATION lib${LIB_SUFFIX}" into "DESTINATION lib/${LIB_SUFFIX}" because this would break the support for the other distributions. I really do not know how to fix it to make it work for all distributions. Any ideas? > well, you can send patches upstream, it is fine by me to avoid debian > patches as long as the mistakes are in the code and not seen by normal > users (I can also accept a mistake in some obscure code that is mostly > unreachable, but I would bother about sending bugs upstream and fix in > a later release) cheers, G. I've sent the the codespelling patch to upstream. The cppcheck errors is only a "Uninitialized variable: c". I think this is not critical. Most of the "$ grep -riE 'fixme|todo|hack|xxx' ." errors occurs on icesupport and this is unused. The rest is not critical, too. Same on licensecheck. It does not affect this package. Cheers, Stefan