Re: binNMU for libthai/libdatrie transition
+ Theppitak Karoonboonyanan (Fri, 17 Apr 2009 15:17:00 +0700):
> On Fri, Apr 17, 2009 at 2:44 PM, Adeodato Simó <dato@net.com.org.es> wrote:
> > m17n-lib has also seen a recent sourceful upload, so no Bin-NMUs are
> > necessary:
> > http://packages.qa.debian.org/m/m17n-lib/news/20090415T103206Z.html
> Please still consider scheduling the binNMU, anyway, as it's still directly
> linked against libdatrie1, which I'd like to get rid of. The sourceful m17n-lib
> upload was done before the recent change to libthai.la, which totally got
> rid of -ldatrie.
Aah, good catch, thanks. Scheduled a Bin-NMU on amd64, i386, powerpc,
and sparc, which are the arches that built m17n-lib/1.5.4-1 fast enough
as to not pick up the fixed libthai. And pango1.0/armel as well.
> > Also, please notify the release team about transitions as soon as
> > possible, and preferably before uploading to unstable. Having libdatrie0
> > disappear from unstable while pango1.0 still linked against it has
> > rendered a big part of the archive unbuildable while we wait for
> > pango1.0 to get rebuild, and that’s rather unfortunate because it slows
> > down our job enormously.
> It's my misunderstanding that the previous preparation by changing
> libthai.pc in unstable was enough for pango to be free from libdatrie0,
> as it was the case for other packages like scim-thai and gtk-im-libthai
> before. But that turned out to be wrong.
> Unfortunately, I forgot the fact that libthai-dev still ships libthai.la,
> not really for linking purpose, but to only satisfy Thai KDE users'
> needs, as kdelibs 3 requires *.la to dlopen()!
> So, I've recently updated libthai.la to get rid of the problem.
> I was about to request for binNMU but the binNMU for pango
> was quick enough. So, I just waited for buildd to finish the
> builds on some archs before requesting m17n-lib.
The thing is that it’s infinitely better to rebuild pango1.0 and make it
depend on libdatrie1, and then rebuild it again once libthai was fixed
in order to make the dependency go away completely, than to wait and
rebuild it only once when a fixed libthai is available. Because with the
former way you don’t render it uninstallable at any point, but with the
latter you do.
Of course, you weren’t supposed to be aware of this, since it’s rather
specific knowledge, so no blame is involved. :-)
> Sorry for the inconvenience. Things didn't go as planned.
> I'll contact release team sooner next time for similar case.
That’s great, thanks.
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
Reply to: