[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