Re: Bug#782475: Bug#787542: libudev1-udeb depends on missing libcap2
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 <debian@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
Reply to: