[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Updating isc-dhcp udeb to dynamically link bind (was: Bug#762762: nmu fixing bind issues)

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.


Attachment: signature.asc
Description: Digital signature

Reply to: