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