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

[Cyril Brulebois]

#include <hallo.h>

Christian Kastner <debian at kvr.at> (2015-06-07):
> 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.

Yeah, and that tool is indeed present in the devel chroot I used to
build systemd in recently. ;)

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

I'm obviously biased as in: I'd like to get d-i buildable again ASAP,
but I don't feel like this gperf issue has to be tackled right now; it
wouldn't be a regression from -8, so I'm happy if it can wait a little.
Once the upcoming upload reaches testing, having gperf entirely disabled
or properly enabled (build-dep + symbols handling) looks fine.

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

I've just checked that (baring apt install/purge gperf where needed) I'm
able to build libcap2, upgrade the relevant packages, build systemd and
get installable udebs (case in point: libudev1-udeb). I wouldn't call
the dependencies correct though, as it only depends on libcap2, without
any version.

We tend to use the -V'libfoo (>= minver)' syntax, which allows to get
proper shlibs (version for both libfoo and its udeb), while still
letting symbols take precedence for the library.

Here's the generated shlibs with your .dsc:
  libcap 2 libcap2
  udeb: libcap 2 libcap2-udeb

And with this extra dh_makeshlibs flag:  -V'libcap2 (>= 1:2.10)
  libcap 2 libcap2 (>= 1:2.10)
  udeb: libcap 2 libcap2-udeb (>= 1:2.10)

Let's compare dependencies, yours:
 Depends: libc6-udeb (>= 2.19), libcap2-udeb

and mine:
 Depends: libc6-udeb (>= 2.19), libcap2-udeb (>= 1:2.10)


But I didn't play with other libcap2 reverse dependencies to make sure
there's no changes for libraries there.

I've also re-checked that d-i still builds correctly (phew!) with this
flag, libcap2 and systemd rebuilt.


Long story short: the source package you published is good enough to
unstuck the dependency issues, but it would probably be a good idea to
fix that properly, adding the -Vfoo flag. Disabling gperf support for
the time being can either be done right now if someone has a patch
handy, or in a later revision.


Mraw,
KiBi.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20150608/6a172f62/attachment-0002.sig>