Michael Gilbert <mgilbert@debian.org> (2014-10-05): > On Sun, Oct 5, 2014 at 7:02 PM, Cyril Brulebois wrote: > > 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. > > It's a rarely used path through the build system (--enable-exportlib), > so it's sort of unsurprising that there was a lurking issue. > > Anyway, in the meantime I fixed the problem. Thanks for the prodding. I haven't build-checked it but that's the kind of easy fix I'd have expected indeed, thanks. > > 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. > > I was trying to avoid an explosion in the number of udebs, but I get > your point now that won't work. I've split up the udebs now so things > can be properly versioned. That looks better from a quick glance, yes. (Not that it matters much but you should use Package-Type.) > > 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. > > Maybe I've addressed your concerns, maybe not, but please consider the > revised changes attached. I'm not going to go through building this on a kfreebsd porterbox to try and figure out how isc-dhcp would look if rebuilt against such packages, but that looks a saner base for porters to build upon. That doesn't make the timing issues I've mentioned disappear though. I'm OK with thinking about it again if porters endorse/welcome/successfully test the resulting packages and installation images. Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature