[Pkg-ime-devel] Bug#651488: Bug#651488: support Multi-Arch

Osamu Aoki osamu at debian.org
Sat Dec 10 01:59:42 UTC 2011


Hi,

Thanks.  Your reply solved all my qestions but caused one more question
to fix another bug.

On Fri, Dec 09, 2011 at 08:44:38AM -0800, Kees Cook wrote:
> Hi Osamu,
> > #Q3 do we need to hardcode exact $DEB_HOST_MULTIARCH as below.  What is
> > the negative of just using * for those location as below?
> 
> The problem comes when multiple architectures are installed on the system,
> or potentially, only the non-native version is installed. In which case "*"
> would match it, but not actually be available. Since the xinput.d script
> runs only for the native system, it needs to examine its environment from
> only the native library perspective. At least that is my understanding of
> the logic in that script.

That was my thought too.  Good.  I do not expect this to be high risk
but why not do it this way, since ibus is an arch any package,
$DEB_HOST_MULTIARCH can be hardcoded in for im-switch.

This means im-config should do the same to be safer but how to do the
same for im-config which is an arch all package.

  FYI: I am deprecating im-switch and pushing im-config.  im-switch is
  over engineered and harder to extend to support cases like requiring 2
  independent packages for activating IM (GTK2+GTK3).  The only negative
  of im-config is that its driving data are all in one package so
  maintainer has to fix for every IM.  But this negative can be sais as
  positive of good consistency.

I guess I need to set it in the run time using $DEB_BUILD_MULTIARCH or
$DEB_HOST_MULTIARCH ?

Since $DEB_HOST_MULTIARCH seems for target machine, $DEB_BUILD_MULTIARCH
seems to be the right choice to know from the native library perspective
in run time.

To get this, is the use of dpkg-architecture best way or simpler way.

Osamu





More information about the Pkg-ime-devel mailing list