Frans Pop wrote: > As you may know, dependencies on glibc udebs are the only category that is > still incorrect [1]. This is an attempt to fix that. > > Normally we would add an option '--udeb <udeb name>' to the dh_makeshlibs > call in debian/rules. However, in the case of glibc this does not work. > Reason is that two libraries (libnss-dns and libnss-files) that are both in > the regular libc6 package, have been split out into separate udebs. > Another (minor) reason is that not all libraries are copied into udebs, so > adding udeb: lines in the shlibs files for those seems redundant. > > Solution I have come up with is to write a small script that will generate > the udeb: lines _after_ dh_makeshlibs has generated the basic shlibs file. > > As an example, the output of the script on amd64 is: > udeb: ld-linux-x86-64 2 libc6-udeb (>= 2.7-1) > udeb: libm 6 libc6-udeb (>= 2.7-1) > udeb: libdl 2 libc6-udeb (>= 2.7-1) > udeb: libresolv 2 libc6-udeb (>= 2.7-1) > udeb: libc 6 libc6-udeb (>= 2.7-1) > udeb: libutil 1 libc6-udeb (>= 2.7-1) > udeb: libcrypt 1 libc6-udeb (>= 2.7-1) > udeb: librt 1 libc6-udeb (>= 2.7-1) > udeb: libpthread 0 libc6-udeb (>= 2.7-1) > udeb: libnss_dns 2 libnss-dns-udeb (>= 2.7-1) > udeb: libnss_files 2 libnss-files-udeb (>= 2.7-1) > > Any comments on this approach and the patch before I proceed [2] with this? > > Joey: do you see any chance to incorporate this in debhelper, or is adding > it glibc the better option? Since splitting udebs differently than the debs are split is a special case that seems likely to affect other libraries than glibc, I'd prefer to keep the special case in glibc, rather than in dehelper. BTW, has anyone looked at how library symbols files interact with udeb: lines in shlibs files? The symbols file tend to override the shlibs files, and I wonder if this won't result in bad dependencies in udebs as the libraries they depend on are converted to have symbols files. -- see shy jo
Attachment:
signature.asc
Description: Digital signature