Hi, a brief update follows:
On 2015-08-17 11:36, Christian Kastner wrote: > On 2015-06-08 00:43, Michael Biebl wrote: >> Am 07.06.2015 um 23:59 schrieb Christian Kastner: >>> On 2015-06-07 23:22, Cyril Brulebois wrote: >>>> Christian Kastner <deb...@kvr.at> (2015-06-07): | @@ -1,4 +1,5 >>>> @@ | libcap.so.2 libcap2 #MINVER# | + __cap_lookup_name@Base >>>> 1:2.24-9 | _cap_names@Base 1:2.10 | _libcap_strdup@Base >>>> 1:2.10 >> >>>> More seriously, I'm not sure it should be exposed in the shared >>>> library, so you may want to unexpose it instead of just adding >>>> it to the symbols file. > > This symbol was only generated and exported when gperf was present > in the build environment. As I've just added gperf as a Build > Dependency, I also added a patch that unexposes it. > >> When you are going to tackle this, _cap_names and _libcap_strdup >> look like they should be hidden as well, at least I can't find >> those symbols in the header files. > > This is a bit more troublesome, and I'd appreciate your advice. > Would you consider it safe to simply drop these from .symbols? > > As you say, they aren't present in any of the headers, and their > name alone strongly suggests that they shouldn't be public in the > first place. > > Nevertheless, they /are/ currently public, so I feel somewhat > hesitant to perform an action that would, in other cases, even lead > to a SONAME bump. Using Debian Code Search, I found at least one mention of _cap_names, in package openSCAP [1], even though that instance is ancient and applies only to and older version of libcap (pre-squeeze). Therefore, I'm skipping this change in the upcoming upload, and will instead create a cleanup patch and send it upstream, and see what the response is. Regards, Christian [1] http://sources.debian.net/src/openscap/1.2.3-1/src/OVAL/probes/unix/process58.c/?hl=90#L85
