On Mon, Sep 2, 2013 at 12:01 AM, Aaron M. Ucko <u...@debian.org> wrote: > Good point; that's indeed a better choice. At any rate, the build now > succeeds modulo symbols mismatches; I've attached the diff I get for > kfreebsd-amd64, but presume you'll need to account for hurd-i386 and > kfreebsd-i386 too (or simply stick with the traditional shlibs system, > as the symbols approach may not be worth the trouble for C++ packages > with few reverse dependencies).
I would reduce the level for dpkg-gensymbols so that build won't fail again and collect this diff together and patch the symbols file. I prefer symbols files over d-shlibs as it is supposed to do more help than just having shlibs system. > >> He additionally reported some problem with d-devlibs which deduces >> library dependency from soname and hence deduces libc0.1-dev as libc on >> kFreeBSD has soname of 0.1. > > Meanwhile, that was actually correct as is; libc*(-dev)'s precise name > varies by architecture and always matches the SONAME. Specifically, > although most Linux architectures have libc6(-dev), ia64 has > libc6.1(-dev), kfreebsd-* has libc0.1(-dev), and hurd-i386 has > libc0.2(-dev). Please simply trust d-devlibs rather than hardcoding > any specific names, though. Uh oh I just noticed that there is a package called libc0.1-dev on kFreeBSD so my override was not necessary. So I'm just wondering why pinotree got FTBFS which read libc0.1-dev no such packages please report to d-devlibs maintainer (one of which is me). Can you do me a favor remove the --override='s/libc0.1-dev/libc6-dev/ line in rules which is given as option for d-shlibmove and try building it to see what exact error you get.. I want to clear an FTBFS before it happens ;-) > > Thanks for checking! Thanks for the continuous support :-) Cheers -- Vasudev Kamath http://copyninja.info copyninja@{frndk.de|vasudev.homelinux.net} -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
