[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#782475: Bug#787542: libudev1-udeb depends on missing libcap2



Hi,

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.

Thoughts?

Regards,
Christian


Reply to: