[Pkg-ime-devel] Re: Bug#283047: scim-uim_0.1.3-1(hppa/unstable): FTBFS: missing build-depends?

Osamu Aoki osamu@debian.org
Sat, 27 Nov 2004 09:03:29 +0100


clone 283047 -1
retitle -1 libuim-dev: should provide Depends: libm17n-dev
severity -1 serious
thanks

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.

> 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 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

I see many -dev packages have this kind of dependency when packages are
linked. (Version dep may be needed.)

For the record, I duplicated bug.  If the maintainer feels I am wrong,
you can close it.  Since this is Omote-san's package, I do not need to
worry about sponsoring.

> This problem can be solved simply by adding libm17n-dev into
> build-depends.  However, I have two questions:

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 vote for removing access to libm17n through uim for scim.
Direct access is enough and better.

Can you think of patch to remove support of libm17n from scim-uim as a
post sarge project?  (low priority)

I think that, when ever we have multiple path, we need to prune those to
minimum.  Currently, anthy can be accessed scim->uim->anthy or
scim->m17n->anthy.  I wonder what happens once scim-anthy is packaged.
This needs good discussion.

> 2. In such a situation, since it's libuim pulling in libm17n, shouldn't
> libuim-dev depends on libm17n-dev directly to avoid such problems?  I
> read the policy, new maintainer's guide, and the library maintainer's
> guide, but never really figured out the rule for development library
> packages.  Could someone shed light on this?

Yes. I think so too.

> So this is what I have found out.  I'll leave the decision to the
> developers who use scim-uim and scim-m17n.  I believe a simple
> libm17n-dev build-depends will solve the FTBFS bug, but haven't get
> around to test yet (need to fix and update my development environment
> first).  If nobody else does the test, I'll do it myself tomorrow
> afternoon US time (UTC Saturday around 22:00), and provide a patch if it
> works.

Let's add version depends on libm17n-dev to scim-uim.  Something like
one of the following:

 libuim-dev (<> 1:0.4.5+r1576-1, >=1:0.3.9-1) 
 libuim-dev (<> 1:0.4.5+r1576-1) 
 libuim-dev (>> 1:0.4.5+r1576-1) 

(Are these correct syntax?)

Osamu