Michael Gilbert <mgilb...@debian.org> (2014-10-05): > Dear hurd and kfreebsd porters. I plan to upload the attached patch, > which along with the previous upload introduces a bind udeb, which > will be dynamically linked by the dhcp udeb. Please let me know if > this looks ok.
NAK. > +bind9 (1:9.9.5.dfsg-4.2) unstable; urgency=low > + > + * Non-maintainer upload. > + * Disable parallel build. Closes: #762766 If parallel building worked before you changed things, you get to fix the issues rather than working around them. bind9 is a pain to build, so having to deal with a forced -j1 is a nasty regression. > + * Set -fno-delete-null-pointer-checks. Closes: #750760 > + * Fix dependencies for libbind-export-udeb. Closes: #762762 This udeb doesn't make any sense to me. $ cat ./debian/libbind-export-udeb/DEBIAN/shlibs libdns-export 100 libbind-export-udeb libirs-export 91 libbind-export-udeb libisc-export 95 libbind-export-udeb libisccfg-export 90 libbind-export-udeb The udeb is unversioned. ABI is going to be broken as usual in later uploads, meaning the udeb shipping these shared objects will break reverse dependencies: /usr/lib/libisccfg-export.so.90.1.0 /usr/lib/libdns-export.so.100.2.2 /usr/lib/libirs-export.so.91.0.0 /usr/lib/libisc-export.so.95.5.0 /usr/lib/libdns-export.so.100 -> libdns-export.so.100.2.2 /usr/lib/libisccfg-export.so.90 -> libisccfg-export.so.90.1.0 /usr/lib/libirs-export.so.91 -> libirs-export.so.91.0.0 /usr/lib/libisc-export.so.95 -> libisc-export.so.95.5.0 I really fail to see how you could possibly imagine anything could work. Since we're late in the D-I release cycle, since we're late in the release cycle in general (window for transitions closed past month), since there was no coordination whatsoever, and since there is apparently no well thought through plan, I think I'll oppose isc-dhcp's using such a udeb. debian-release@ in Cc: to let the team now I might just block the bind9 package to make sure this udeb never reaches testing. Mraw, KiBi.
signature.asc
Description: Digital signature
