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

[Christian Kastner]

Hi again,

On 2015-06-07 23:22, Cyril Brulebois wrote:
> Christian Kastner <debian at kvr.at> (2015-06-07):
>> Sorry for the delay, I was AFK until just now.
>>
>> I've prepared a quick upload consisting of only Matthias' patch, minus
>> the superfluous d/shlibs.local as discussed in Michael's follow-up to
>> the patch.
>>
>> I do still need a sponsor, though. For whomever is willing to act as
>> such, a source package can be obtained from the following link,
>>
>>     http://www.kvr.at/debian/pool/main/libc/libcap2/libcap2_2.24-9.dsc
>>
>> or, alternatively, via the git repo
>>
>>     git://anonscm.debian.org/collab-maint/libcap2.git
>>
>> using gbp.
>>
>> Please let me know if there is anything else I can do.
> 
> I've just tried to build your package, to rebuild systemd and d-i
> afterwards but it failed with:
> | dh_makeshlibs -plibcap2 --add-udeb=libcap2-udeb -- -c4
> | dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below
> | dpkg-gensymbols: warning: debian/libcap2/DEBIAN/symbols doesn't match completely debian/libcap2.symbols
> | --- debian/libcap2.symbols (libcap2_1:2.24-9_amd64)
> | +++ dpkg-gensymbols1MqufS	2015-06-07 23:13:54.633114251 +0200
> | @@ -1,4 +1,5 @@
> |  libcap.so.2 libcap2 #MINVER#
> | + __cap_lookup_name at Base 1:2.24-9
> |   _cap_names at Base 1:2.10
> |   _libcap_strdup at Base 1:2.10
> |   cap_clear at Base 1:2.10
> | dh_makeshlibs: failing due to earlier errors
> | debian/rules:50: recipe for target 'override_dh_makeshlibs' failed
> 
> This doesn't happen with 1:2.24-8. Trying to build it a while ago led to
> no warnings, but (re)building it now introduces this new symbol.
> Probably due to some toolchain update (that I didn't investigate).

I looked into this and I can reproduce the issue. In one of the
Makefiles, there's a test for the presence of gperf(1), and if so, stuff
happens, and the above symbol eventually gets added.

> Having -9 introduce the -c4 flag makes the warning become a fatal error,
> since the default behaviour (level 1 in dpkg-gensymbols, called by
> dh_makeshlibs) is warn only.
> 
> It's somewhat fun to see how this function is constructed by the way. ;)

Well put :-)

> 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.

With regards to the cause listed above, I'd rather just disable this
"feature"  entirely, and (possibly, if it makes sense) add gperf as a
B-D at a later point, and then deal with the symbol as you recommend.
Either way resolves the current nondeterminism in the build, which is at
the moment what bothers me the most, TBH.

Would you like me to prepare a 1:2.24-10 with such a fix ASAP (which
would be tomorrow)? Or is the above info enough for you to deal with
this issue for the moment?

Regards,
Christian