Hi, sorry it took me so long to get to this issue!
On 2015-06-08 01:31, Cyril Brulebois wrote: > 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. Your point is clear to me, and I've just committed a fix for it. Thank you for the pointer and the explanation. TBH, with symbols files taking preference, I never really even thought about looking at shlibs, but you're right, of course: this inconsistency should be fixed Regards, Christian
