[Pkg-ime-devel] Re: Bug#283047: scim-uim_0.1.3-1(hppa/unstable): FTBFS: missing build-depends?
Ming Hua
minghua@rice.edu
Sat, 27 Nov 2004 20:09:55 -0600
On Sat, Nov 27, 2004 at 09:03:29AM +0100, Osamu Aoki wrote:
> Hi Ming, nice to hear from you.
>
> On Fri, Nov 26, 2004 at 08:59:21PM -0600, Ming Hua wrote:
> > Hi everyone,
> >
> > The scim packages are going fine, and scim-uim just got accepted to the
> > repository by ftp master. However, scim-uim now FTBFS on all arches.
> > The reason looks like a simple missing build-depends, but it is actually
> > more complicated. So I am asking the whole list for opinions,
> > especially those who use scim-uim or scim-m17n themselves.
>
> Although scim-uim is practically for Japanese only scim-m17n seems to
> aim wider scope.
Yes it seems so. Thus I agree with your opnion -- direct access is
better than indirect one. We should try to avoid seeing all m17n IMs in
scim-uim if possible (and also avoid seeing the anthy ones when
scim-anthy is packaged.)
> > The details can be see at the BTS (bug #283047):
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=283047
> >
> > The short summary is: scim-uim build-depends on libuim-dev. After the
> > scim-uim packages are prepared, uim packages enabled m17n support and
> > libuim-dev indirectly depends on libm17n-0 now (through libuim0).
> > With this new libuim-dev package, the command
> > pkg-config --libs "uim >= 0.3.9"
> > generates "-luim -lm17n" instead of only "-luim" as before.
> >
> > However, scim-uim doesn't have libm17n-dev as build-depends, but the
> > configure script happily generates makefile with commands linking to
> > libm17n. So the build fails miserably.
>
> I think libm17n-dev should depend on libm17n. Let's fix bug there.
> (Omote-san on this list is the maintainer)
I think you meant libuim-dev should depend on libm17n-dev here, didn't
you?
> I am a bit confused. Ming sounds like suggesting later part as:
>
> Package: libuim-dev
> Section: libdevel
> Architecture: any
> - Depends: libuim0 (= ${Source-Version}), uim-common
> + Depends: libuim0 (= ${Source-Version}), libm17n-dev, uim-common
> Description: Development files for uim
Yes that's what I meant. And then we can depend on a versioned
libuim-dev to solve the FTBFS bug. But also see below.
> I see many -dev packages have this kind of dependency when packages are
> linked. (Version dep may be needed.)
I read similar opnions in Debian Library Packaging Guide
(http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#AEN80).
To quote:
"The -dev package should depend on all -dev packages for libraries
that the library package depends upon..."
But this is actually a very strict requirement (since you are pulling in
many -dev packages you don't even know through dependecies). And it
generates quite long Depends: list for -dev packages. From what I see,
few -dev packages follow this practice. For example, our scim-dev
package don't do this.
I also read somewhere saying this comment is outdated now, altough I
can't remember where exactly. So I am really not sure what is the right
way to solve this bug.
> This is very good analysis.
>
> > 1. Is it desirable to have scim-uim access the m17n input methods? I
> > know that you can directly use scim-m17n, and if you have scim-uim with
> > all m17n stuff included, and scim-m17n as well, you'll end up with a lot
> > of duplicated input methods. So what do the uim and m17n users prefer?
> > Do the uim users usually need the m17n IMs as well? Do the m17n users
> > prefer to access directly with scim-m17n, or though uim with scim-uim?
> > In my opinion, we really should only provide one way to access m17n IMs
> > in scim, if just to avoid confusion. But which one?
>
> If uim-xim (non-scim environment to use uim) is used as IM method
> instead of scim-uim, this uim-xim method has no access to m17n library
> unless it is provided through uim like now. But for scim environment,
> scim-m17n exists and this is causing duplicate entry in scim listings. I
> personally do not like to have things this way.
I realize uim needs to depend on m17n to provide those IMs for non-scim
users, I would never object that.
> I vote for removing access to libm17n through uim for scim.
> Direct access is enough and better.
As I've said, I agree. But again, since I use neither uim or m17n, my
vote doesn't really count. :-)
> Can you think of patch to remove support of libm17n from scim-uim as a
> post sarge project? (low priority)
There are ways to disable m17n IMs in scim-uim from configure file. I
think we should be able to ship something to disable them by default.
But I can't think of any way to remove m17n support from scim-uim in the
current situation.
Ming
2004.11.27